telnet があれば、RAWプリンタで印刷できる

telnet ですかー！？
telnetがあれば、TCP9100のRAWポート印刷に対応しているネットワークプリンタから印刷できる。
 
lprコマンドとかの立場はまあおいといて。
 
 

取りあえずそこらにネットワークプリンタがあったら、Telnetで9100番ポートに繋いでみよう。

telnet [プリンタのIPアドレス] 9100

セッションが張れたら任意の文字を入力しよう、コピペでもOK。
 
 

そしておもむろに「 Ctrl+]」 でエスケープ(Windows・Linuxと多分共通)、「telnet >」のプロンプトで "c" または "close" と入力してセッションをクローズしよう。
 

印刷された？
 

telnetシリーズタグ

Base64符号化で簡単な組み合わせを編み出す

頭に結論を書いてしまうと、一番簡単なのは
UUU(平文で3文字) ⇔ VVVV(Base64で4文字)
だと思うんです。もちろん「UUUUUU」 ⇔ 「VVVVVV」 もあり。
※追記：「DDD」⇔「RERE」 も覚えやすい。
 
 

Base64への道のり

ちょっとしたテストをTelnetでしたいときに、Base64エンコードが必要なケースがある。そんなときにツールやPerlを呼ばなくても簡単にできたらよいなと思って仕組みを調べてみた。

平文はこのようなプロセスを経てBase64文字列になる

1. 各文字をASCIIコードに変換する


2. 得たASCIIコードを2進数(8ビット)に変換して並べる


3. 並んだビット文字列を6桁(6ビット)ずつ区切る、最後足りない分は0をつける


4. 6ビットの文字列をBase64文字列変換表を参考にBase64文字列に変換する、これは一応4文字づつ


5. できた文字列が4の倍数に満たない場合は=(イコール)をパディング、符号化完了

 

Base64変換について、普通はperl一行野郎などで変換してもらう。
$ perl -MMIME::Base64 -e "print &MIME::Base64::encode_base64(hogehoge);"
encode_base64関数でhogehogeを変換して表示する。自分用メモ

 

最小公倍数の24ビットを軸にする

変換の仕組を調べて、暗算するには相応の努力が必要だということが分かったので楽な方法を考えることにした。。
 
「ASCII ＝ 8ビット」、「Base64 = 6ビット」 ということは公倍数の24ビットの所で丁度キリがよくなる。
つまり平文3文字をBase64で符号化すると4文字になり、その組み合わせは1対1と言うことになるので、Base64変換表からよさそうなのを探す。
 
「010101 = V」
 
これならどこで切っても同じになる、これがよさそう。
 
 

変換して確かめる

さて、Base64なので4文字並べて「VVVV」
これをそれぞれ6ビットに変換して「010101 010101 010101 010101」
8ビットに繋ぎかえて「01010101 01010101 01010101」
ASCIIに変換すると「UUU」
 
 

3文字単位ならいくら並べてもOK、たまに使い道があるかもしれない。他にも簡単な組み合わせがあったら是非教えて欲しいですね。
 
 

まとめ

結局、Basic認証ではコロンがいるし、メールアカウントではアットマークが必要なことが多い、それがネックだ。
一応3文字のユニットとして扱えば覚えておけないこともないかも知れないので書いておこう。
 

「U:U = VTpV」
「U@U = VUBV」
 

よし、メールは複数ドメイン環境では無理だな。

telnet があれば、サーバ間でファイルの転送ができる(後編)

前編からの続き
telnet があれば何でもできる！ と言ってみたかっただけですが。
 

ということで、telnet2本使いによるFTPファイル転送を実際にやってみる。
実験にはIISのFTPサーバを使い、サーバ間のファイル転送ができるかを確かめた。
 
 

突然つまづく、最近はデフォルトセキュア(寄り)なのか…

リハーサルとして一通り試していたら、PORTコマンドの所でどうしてもつまづく。
パケットキャプチャしたら、PORT発行後もIPによる通信すら しに行っていない様子。IISの設定を見直すためにMSへ。

Microsoft TechNet : サーバーからサーバーへの FTP 転送
http://technet2.microsoft.com/WindowsServer/ja/library/f5c810d2-a0cd-44a9-ba14-0ed5c09264bb1041.mspx?mfr=true

 
なるほどそうか。最近はそんなことやらないからか、単に脆弱性の脅威からか、デフォルト設定ではできない。レジストリをいじってFTPサービスを再起動しないといけなかった。
レジストリ変更箇所は下記。

ファイル受信側 (PASV)	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSFTPSVC\Parameters\EnablePasvConnFrom3rdIP=1 ※第3者からのデータコネクションを許可する
ファイル送信側 (PORT)	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSFTPSVC\Parameters\EnableDataConnTo3rdIP=1 ※第3者あてへのPORTコネクション接続要求を受け付ける。

これで問題はなかろう、よそへのPORTコマンドもちゃんと受け付けてくれる。
 
 

そして実験へ

test.txtと言うファイルを転送してみる。

ファイル受信側	ファイル送信側	メモ
USER hogehoge PASS *****   230	USER hogehoge PASS *****   230	ユーザ認証してログインOK
PASV   227 Entering Passive Mode (xxx,xxx,xxx,xxx,xx,xx).		待ち受けポートを決定する。 xxxはIPアドレスと待ち受けポート
	PORT xxx,xxx,xxx,xxx,xx,xx   200 PORT command successful.	データ転送用のセッションが確立
stor test.txt   125 Data connection already open; Transfer starting.		STORでローカルに空ファイル"test.txt"作成、 データの受け入れ準備
125 Data connection already open; Transfer starting. 226 Transfer complete.	retr test.txt   150 Opening ASCII mode data connection for test.txt(23 bytes). 226 Transfer complete.	RETRで "test.txt"ファイルを転送、 受信側は待ち構えていた"test.txt" にASCIIデータとしてデータを送り込んで完了

 

OK、うまく行った。
 
 

次はどうしよう。
定番の「telnet があれば メールの送信ができる」や、「telnet があれば HTTPコンテンツを受け取れる」、あたりでやっておきたい。

telnet があれば、サーバ間でファイルの転送ができる(前編)

telnet ですかー！？
と、分からないかもしれないネタはこの辺にして、「telnet があれば、サーバ間でファイルの転送ができる(前編)」と題して FTP (File Transfer Protocol) の仕様を確認するコラム。
 
 

前置き、PASVコマンド

FTPというと、通常のPORTコマンドを使うやり取りを初めて理解したときは驚いた。
「PORTコマンドの発行を受け付けたサーバは、接続元ポートTCP/20 でクライアントにむけてTCPセッションを張りに来る。」
そうやって接続されたセッションがデータ転送ポートとして、ファイルリストのテキストデータや、バイナリデータの転送に使用される。
 

嘘やん、そんなのこちらポート空けてないのにどうすんの？って思う節があるかもしれないが、最近のファイアウォールやルータはその辺をヨロシクやってくれて、意識しなくてよいようになっている。
しかしそうではないルータの下にいるFTPクライアントの為に、PASVを使うという手順がある。
 
 

FTPサーバがPASVコマンドを受け付けると、任意のポートでLISTEN のTCP状態を取り、クライアントに通知します。
 
    [PASV] → [227 Entering Passive Mode (192,168,10,15,239,11)]
 
カッコ内がカンマ区切りで、IPアドレス・待ち受けポートです。このメッセージからは「IPアドレス：192.168.10.15、ポート：61195」 でLISTENしますよ、と言うこと。ちなみに 61195 は 「239 * 256 + 11」 で計算します。
 
 

PASVに割りこんだらどうなるの？

PASVでポートの通知を受けたFTPのクライアントは、当然LISTENしているポートにTCPセッションを張りに行き、データはこのポートから送信されます。
 
と、ここでPASVで教えてもらったポートに telnet で接続するとどうなるか試した(※実験はPASVも telnet で発行しました。)ら、ちゃんとセッションが張れる。
そのまま最初に接続したコマンド用のセッションで、LISTなど発行すればPASVで張ったほうのセッションからリストデータが、RETRをすればファイルの中身が流れてくるといった具合。
 

基本的に接続元の制限などない模様なので、これはこれで危なっかしいとも思えるが、もうちょっと突っ込んで考えてみる。
 
 

PORT と PASV の組み合わせで、と思ってRFCを参照する

使わないから意識していなかったが、FTPはサーバ同士のデータ転送という役割を与えられたプロトコルでもある、と言うのを形だけ知っていた。
上の割り込み実験から、「PASV で待ちうけ、PORTで接続」 とすればサーバ間の転送ができるんじゃないかと思って、RFCを読んでみた。
   RFC:959(原文)(日本語訳)
 

すると、「5.2. CONNECTIONS」 の所にしっかり書いてあった、今でこそ一般的ではないやり方だけど、RFCでは一番シンプルなFTPの使い方としてサーバ間のデータ転送が紹介されている方法だった。
 
 

telnet2本張って サーバ間のデータ転送

コントロールはクライアントから、データの転送は2台のサーバ間で。
サーバA(SV-A)からサーバB(SV-B)にファイルを転送したい場合、ざっとこういう手順で達成できるはず。図が崩れてたらごめんなさい、Firefoxだと一応きれい。
 

┌──────┐ ┌──────┐ │ SV-A │ │ SV-B │ └──────┘ └──────┘ ↑ ↑ │ │ │telnet 21 │telnet 21 │ ┌──────┐ │ └←│ Ctrl │→┘ └──────┘	コントロールするクライアントから、両方にtelnet でFTPログイン
LISTEN ┌──────┐ ┌──────┐ │ SV-A │ ★ SV-B │ └──────┘ └──────┘ │ ↑ │ │ │ │PASV │ ┌──────┐ │ └─│ Ctrl │→┘ └──────┘	SV-B にPASVコマンドを発行、ポートをLISTENさせる
LISTEN ┌──────┐ ┌──────┐ │ SV-A →───→★ SV-B │ └──────┘ └──────┘ ↑ │ │ │ │PORT(SV-B) │ │ ┌──────┐ │ └←│ Ctrl │─┘ └──────┘	SV-Bが待ち受け中なので、SV-AへPORTコマンドを送る。送信内容はSV-BのIPアドレスとポート すると、SV-A と SV-B の間でFTPデータ用のセッションが確立するはず
┌──────┐→data→┌──────┐ │ SV-A ＝＝＝＝＝＝ SV-B │ └──────┘ └──────┘ ↑ ↑ │ │ │RETR(File) │STOR(File) │ ┌──────┐ │ └←│ Ctrl │→┘ └──────┘	後編作成後に認識間違いを修正。図も修正。 初版ではここの解釈に嘘があった、STORで待ち構え、RETRで送るというオペレーションが必要ということだ。   (初版)データコネクションが確立したら、STORコマンドでファイルの転送が行えるはず。 RFCではSV-B側でRETRコマンドが必要とあったが、この辺がよく分からない。

 

さて、手元に実験できるサーバがないので今度試してみよう。
後編につづく