TCL上のWebshel​​l、Cisco IOSなど向け

私は、 tclshコマンドの背後に隠され、ほぼすべてのルーターとスイッチに存在するCisco IOSの機能を長年実践したいと考えていました。 しかし、残念ながら、幸いなことに、デバイス自体による自動化を使用することで少なくとも何らかの形で助けが得られる問題を解決する必要はなかったかもしれません。 最後に、運命は私をネットワークの管理が必要な場所からの出張に投げ込み、私の手にはWi-Fiと80番目のTCPポートを備えたタブレットだけを投げました。 今回は、電話で音声でコマンドを口述する必要がありましたが、到着時にタスクはTclを使用したCisco IOSスクリプトを使用して解決されました。 幸いなことに、Cisco IOSのTCL実装は、このような問題を解決するのに十分機能しています。

まず、既製のソリューションを探しました。 実際、Cisco自体はWebベースのインターフェイスを介してデバイスへのアクセスを提供しますが、そのようなアクセスにはコンソールインターフェイスのすべての機能が完全に備わっておらず（Cisco自体が示すように）、予備設定（たとえば、SDMのJava）が必要であり、セキュリティに影響を与え、使用するのが便利ではありません（私にとって）-一般に、すべてのデバイスでip http serverはありません 。 SSH / telnetポートをHTTPにマップすることもできましたが、これはタブレットの問題に過ぎません。telnetは既にWindowsからなくなっており、sshです。 私たちは、それが2000年代初期/中期の電話であっても、ウェブブラウザを備えたデバイスから可能な限り迅速にログインする必要があるかもしれないことを考慮します。

Ciscoコンソールへのリモートアクセス用のサードパーティ製既製ソリューションを調べます。 これはおそらくこのトピックに関する最も人気のある記事ですが、少なくともtelnetが必要であることを忘れないでください。 その結果、要件を定式化します：Webインターフェイスを介したアクセス、可能な限り簡単にデバイス上で起動し（理想的には1つのコマンドで）-すべてを自分で記述します。

まず、何が起こったのか-投稿の最後にあるリンクをクリックすると、リモートデバイスで実行するスクリプトを選択できます。 非常に多くのシステムにTCL実装があるため、Cisco IOS、Windows、Linux、FreeBSDにアクセスできます（これは私が自分で確認したものです）。 パラメーターでは、着信要求をリッスンするアドレスとポートを指定する必要があります。 パラメーターを指定しない場合、すべてのアドレスと、システムによって割り当てられた最初の空きポートをリッスンします。 疑問符がパラメータに表示される場合、ヒントの類似点があります（Ciscoの場合）。皮肉なことに、ヒントはCiscoコンソールでは機能せず、Ciscoコンソール自体が疑問符をインターセプトします。 最初の行には標準の＃！<スクリプトへのパス>が含まれていないため、明示的にtclshを呼び出します（Ciscoの場合、別の方法では不可能です）。

win>tclsh cws.tcl ? ABCD or * Listen ip address <cr> win>tclsh cws.tcl * ? <0-65535> Listen tcp port, 0 for first free <cr> win>tclsh cws.tcl * 8181 Listen on http://0.0.0.0:8181
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ciscoコンソールの場合、フルパスを（tftpを介して）書き込むため、特権モードである必要があります。 tclshモードでは、スクリプトはsourceを介して呼び出されますが、コマンドラインパラメーターをスクリプトに渡すことはできません。

 cisco#tclsh tftp://192.0.2.1/cws.tcl * 8181 Listen on http://0.0.0.0:8181 cisco#tclsh cisco(tcl)#source tftp://192.0.2.1/cws.tcl Listen on http://0.0.0.0:43012
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nixコンソールの場合、パラメータ「*」はワイルドカードパラメータとして認識されるため、「\ *」をエスケープするか、引用符で囲む必要があります。

起動後、リスニングアドレスでブラウザに入ることができます。 インターフェイスは禁欲的です-コマンドを入力するための行、スクリプトを実行および停止するためのボタン、およびtclshモードスイッチ。

実行されたコマンドに出力するものがある場合、コマンドの出力はページの先頭に表示されます。 TclshモードはコマンドをTCLスクリプトとして実行します-言語コマンドのセット全体を使用できます。 入力フィールドは、160文字、サイズ40文字に制限されています（タブレットに便利です）。 スクリプトを停止するボタンはデバイス上でその作業を完了します。アクションを終了するときに他の人に尋ねる必要はありません。 コマンド自体の実行中のエラーは処理され、ウェブインターフェースに出力されます。通信およびスクリプトエラーは一切捕捉されないため、TCLインタープリターの標準エラーはデバイスのコンソールに表示されます（可能な限りすべてを捕捉しようとしましたが、残される可能性があります）。 また、スクリプトは一度に1つのリクエストのみを処理し、インタラクティブなアクションまたは長い実行期間を必要とするコマンドを実行すると、スクリプトをさらに制御するためのアクセスが失われることを覚えておく価値があります。 スペースの後に「＆」文字を使用してコマンドを終了できます。これにより、コマンドがバックグラウンドで起動され、制御がスクリプトに戻されますが、Cisco IOSでは機能しません。

Ciscoのtclshモードの主な機能は、すべてのCiscoコマンドがインタープリターによってネイティブとして解釈されることです。つまり、実際には、特定のデバイスコマンドインターフェイスを持つすべての機能でTCL言語を補完します-execを使用してコマンドを明示的に呼び出す必要はありません実装されています。 また、 conf t端子から設定モードに入ることはできません。これには、Cisco TCLアドオンコマンド-ios_configを使用する必要があります。 たとえば、インターフェイスをオフにします。

 cisco#conf t cisco(config)#int fa0/0 cisco(config-if)#shutdown cisco#tclsh cisco(tcl)#ios_config "int fa 0/0" "shutdown"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これについては、常にcisco.comで詳細に説明しています。

それどころか、Windowsではすべてのコマンドはコンソールで実行されません。つまり、コマンドは個別の実行可能ファイルとしてのみ認識されるため、たとえばdirを実行するには、明示的にコンソールを呼び出す必要があります。

 win>cmd /c dir c:\    C   SYSTEM   : A073-3CE1   c:\
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

機能を完成しました。実装について少し説明します。 TCP接続を受け入れるには、サーバーモードでsocketコマンド-serverスイッチを使用します 。 必要に応じて、リスニング用のアドレスを送信します（そうでない場合、すべてのアドレスがリスンされます） -myaddrキー。 必須パラメーターは、確立された接続でデータが転送されるときに呼び出されるコールバックプロシージャの名前です。この例ではget_httpです。 既に書いたように、接続の作成時のエラーはチェックされません。何か問題が発生した場合、スクリプトはコンソールで誓います。 開いているソケットはwsh変数に保存され、 そこからfconfigure $ wsh -socknameコマンド（画面に表示するリスニングアドレスとポート）でパラメーターを取得します。

 if { $argc == $i } then { if [string length $listenaddr] then { set wsh [socket -server get_http -myaddr $listenaddr $listenport] } else { set wsh [socket -server get_http $listenport] } set sockparam [fconfigure $wsh -sockname] puts "Listen on http://[lindex $sockparam 0]:[lindex $sockparam 2]" after $connwait set stopsrv 1 vwait stopsrv close $wsh set retcode $stopsrv } else { set retcode [expr $i + 100] } return $retcode
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、変数stopsrvが変化するのを待つvwaitを呼び出します 。 このコールバックコマンドがないと、プロシージャは接続を受け入れず、サーバー自体はポートでまったくリッスンしません。 実際、このコマンドを呼び出した後にのみ、サーバーモードに切り替えます。TCLは、接続要求が処理される内部ループに入ります。 接続の処理を停止するには 、 stopsrv変数が必要です-サーバーを停止し、Webインターフェイスの停止ボタンをクリックすると設定されます-TCLはリッスンループを終了し、コールバックプロシージャget_httpを終了してから、 vwaitに続く closeコマンドを実行します。ソケット。 vwaitの前に、保護メカニズムがあります：入ることについて気が変わった場合、または長時間アクションを実行しなかった場合、変数connwait = 15分で設定された時間が経過すると、 stopsrvが設定され、 vwaitの実行が続行されます。 ログインすると、 get_httpプロシージャでafterが再度初期化されます。

ifからのラッパーは、このブロックへのコマンドラインパラメーターの正しい転送に必要です。パラメーター自体は以前にチェックされます。これは、スクリプト自体で確認する方法です。

Cisco tclshの機能を覚えています。Ciscoコマンドはネイティブです。そのため、TCLではなくCiscoを具体的に参照するexitの代わりにreturnを使用します。Ciscoでスクリプトが実行された後、 終了コードがコンソールに発行されます。

主な作業はすべてget_httpプロシージャで行われます。get_httpプロシージャでは、HTTP要求の入力パラメータが分析され、HTTP応答を生成するためにプロシージャが呼び出されます。

 proc get_http { sockaddr ipaddr portaddr } { global stopsrv global connwait gets $sockaddr r flush $sockaddr set rs [string tolower [string trim $r]] after cancel set stopsrv 2 after $connwait set stopsrv 2 switch -regexp -- $rs { {^get\s*/close} { set body 1; set stopsrv 0 } {^get\s*/\s+} { puts "GET from $ipaddr:$portaddr"; after cancel set stopsrv 1 } {^get\s*/\?cmd=} { if { [regexp {/\?cmd=([^[:space:]^\&]*)(&tclsh)?} $r opt cmdline checked] && [string length $cmdline] } then { set cmdline [expandPercent $cmdline] if { ! [string length $checked] } then { catch "exec $cmdline" msgout } else { catch $cmdline msgout set checked {checked} } } } default {set mode 1; set body 2 } } response_http $sockaddr $mode response_html $sockaddr $body $cmdline $msgout $checked close $sockaddr }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このプロシージャのパラメータは次のとおりです。オープンソケットsockaddr 、読み取り元と書き込み先、および参加クライアントのportaddrポートとipaddrアドレス。 グローバル変数stopsrvを定義して、この手順の外でそれを確認します。vwaitに必要です。 最初の行のみを読み取ります（残りは必要ありません-flush ）、GET要求があると予想しています。 スイッチでこれを確認し、クライアントから渡された内容に従って行動します。 何かわからない場合は、「HTTP / 1.0 501」を返します（要求されたコンテンツを表示できません）。 「HTTP / 1.0 200」で正しいリクエストに応答します。

すべてのHTTP応答はresponse_httpプロシージャで生成され、HTMLページはresponse_htmlで生成されます。 これらの手順については説明しません。ページレイアウトを出力するための線形コードは、ほんの数行で$ sockaddr <text>を配置し、表示する条件をチェックします。

以下のリクエストされたデータに対応します。

• /-ルート -ページを表示し、デバイスのコンソールに、誰が来たのかを書き込みます-アドレスとポート。 また、 後に一時停止をキャンセルします。
• / close- スクリプトの作業を終了します -変数stopsrvを設定します（実際、パラメーターのないフォームからのリクエストのように、クライアントから「/ close？」が届きます）。
• / cmd = <command>＆tclsh-最初に、HTTPリクエストからテキストを開きます-すべてのスペースが「+」に置き換えられ、処理された行が到着します。すべての非標準文字（文字と数字を除くほとんどすべての文字）は％XXとして表されます。 このために、ほぼ常にWiki TCLでexpandPercentを使用します。 次に、 catchを介してクリーニングされたコマンドを実行し、結果をmsgoutに保存して、ページに出力します。 この方法でコマンドを呼び出すことにより、実行の可能性のあるエラーをキャッチします。 「tclsh」パラメーターが存在する場合はそのまま実行し、存在しない場合はexecを介して実行します。これにより、デバイスのコンソールでコマンドを実行する効果が得られます。

応答を送信した直後に、ソケットを閉じます。 「キープアライブ」接続をサポートしていないという事実は、「Connection：close」オプションと「HTTP / 1.0」のバージョンを示す各HTTP応答で報告されます。 スクリプトは何らかの基準を満たそうとはしていません。手元にあるブラウザー（Opera 12、IE7、Chrome）が送信されたデータに正常に反応するように、可能な限り最小の処理を行いました。手元にないものでは驚きがあります

Cisco IOSでの直接的な言語構文の特性は、主にTCLバージョン8.3.4が実装されており、最新バージョンが8.5.12であるという事実に関連しています。 たとえば、便利なswitch 、 -matchvar、および-nocaseオプションは実装されていません。 いずれの場合でも、どのプラットフォームでも記述できます。構文に厳密に関連しているだけなので、転送に問題はありません。

コードを少し台無しにしたり、スタイルを使いすぎたり、逆に、一部のデバイスではこれらのデバイスの機能を考慮して起動しないかもしれませんが、全体的にはかなり安定しているように見えました。 これを使用する際の主なことは、これは単なるツールであり、頭をどのように取り付けるかは、誰がこの頭を置くかに依存することを思い出すことです。



スクリプトはリンクから取得できます-cws.tcl

CiscoのTCL-www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_tcl.html

TCLコマンド-www.tcl.tk/man/tcl8.5/TclCmd/contents.htm