uso8000k.net

先週末にわりと重要なメールを相手に送ろうとしたら、メールサーバがGoogleかこの様なメッセージが届く。

This is the mail system at host mail.uso8000k.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

: host xxxxx.google.com[IPv6 Address] said:
550-5.7.1 [IPv6 Address] The sender does not meet basic
ipv6 550-5.7.1 sending guidelines of authentication and rdns resolution of
sending 550-5.7.1 ip. Please review 550 5.7.1
https://support.google.com/mail/answer/81126for more information.
ea8si3107268bkc.295 - gsmtp (in reply to end of DATA command)

どうもGoogleさんのメールサーバは逆引きが出来ないIPv6アドレスについてはお断りを入れるようになったらしい。ワリと突然の変更なので困るところ。逆引きを出来ないアドレスにお断りを入れるのはSPAM等の不正な要求をはじくことが出来るし、IPv4ではわりとよく行う設定であるので、IPv6に対して行うのもの道理ではあるのだが・・・少々乱暴すぎやしないか。せめてTarpittingやGreylist等で猶予が欲しかった。

ということで、色々見て暫くは以下の感じでIPv4へ先祖返り。

$ less /etc/postfix/master.cf

smtp      unix  -       -       n       -       -       smtp
        -o inet_protocols=ipv4

IPv6のトンネリングであったり、VPSのIPv6サービスであったりは自分で正引きの調整は出来ても、逆引きの調整とかも出来ないので、ちゃんとしていないところはユーザはどうしようもなく蹴られてしまうのですよね・・・ちょっと面倒くさいです。IPv6を使う気もなくなるというものよ(言いがかり)

参考: どさにっきLTE gmailの逆引き制限

root@localhost:~/pox # ./pox.py samples.spanning_tree
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
[core                  ] POX 0.1.0 (betta) is up.
[openflow.of_01        ] [00-ab-94-41-63-00 1] connected
[openflow.of_01        ] [00-ab-7c-6d-c3-00 2] connected
[openflow.of_01        ] [00-ab-8c-38-60-00 3] connected
[openflow.discovery    ] link detected: 00-ab-7c-6d-c3-00.2 -> 00-ab-8c-38-60-00.3
[openflow.discovery    ] link detected: 00-ab-8c-38-60-00.3 -> 00-ab-7c-6d-c3-00.2
[openflow.spanning_tree] 6 ports changed
[openflow.discovery    ] link detected: 00-ab-94-41-63-00.2 -> 00-ab-7c-6d-c3-00.3
[openflow.spanning_tree] 1 ports changed
[openflow.discovery    ] link detected: 00-ab-94-41-63-00.3 -> 00-ab-8c-38-60-00.2
[openflow.spanning_tree] 1 ports changed
[openflow.discovery    ] link detected: 00-ab-7c-6d-c3-00.3 -> 00-ab-94-41-63-00.2
[openflow.spanning_tree] 4 ports changed
[openflow.discovery    ] link detected: 00-ab-8c-38-60-00.2 -> 00-ab-94-41-63-00.3
[openflow.discovery    ] link timeout: 00-ab-94-41-63-00.2 -> 00-ab-7c-6d-c3-00.3
[openflow.spanning_tree] 4 ports changed
[openflow.discovery    ] link detected: 00-ab-94-41-63-00.2 -> 00-ab-7c-6d-c3-00.3
[openflow.spanning_tree] 4 ports changed

// VyattaのインターフェイスをONにして環状に
[forwarding.l2_learning] Same port for packet from 00:ab:71:13:2d:00 -> 00:ab:77:e3:4b:00 on 00-ab-8c-38-60-00.1.  Drop.
[openflow.discovery    ] link detected: 00-ab-94-41-63-00.1 -> 00-ab-8c-38-60-00.1
[openflow.spanning_tree] 2 ports changed
[openflow.discovery    ] link detected: 00-ab-8c-38-60-00.1 -> 00-ab-94-41-63-00.1

VyattaのSTPは802.1Dで動いているわけですが、そのままOVS側で重複検出してポート閉じられてしまった。予想通りというかなんというか、それっぽく動くサンプルですし仕方なし。ただ、それっぽい動作をちゃんと検出できたのでよしとする。

Vyattaの中身

vyatta@vyatta# sh interfaces
 bridge br0 {
     stp true
 }
 ethernet eth0 {
     bridge-group {
         bridge br0
     }
     hw-id 52:54:00:12:34:56
 }
 ethernet eth1 {
     bridge-group {
         bridge br0
     }
 }
 ethernet eth2 {
     bridge-group {
         bridge br0
     }
 }
 ethernet eth4 {
     bridge-group {
         bridge br0
     }
 }
 loopback lo {
 }

これだけ。ところで8月1日のエントリでSPTと書いてしまっているわけですが、レイズナーの見すぎですね。

迷走中故、暫くサンプルにて遊ぶ。

root@localhost:~/pox # ./pox.py samples.spanning_tree
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
// 1. POX 起動
[core                  ] POX 0.1.0 (betta) is up.
// 2. 各OVS の OFC接続確認
[openflow.of_01        ] [00-ab-76-94-69-00 1] connected
[openflow.of_01        ] [00-ab-5e-70-a5-00 2] connected
[openflow.of_01        ] [00-ab-f1-37-ae-00 3] connected
// 3. OVS-1の eth2 を切断の状態で通常のスイッチとして動作
[openflow.discovery    ] link detected: 00-ab-f1-37-ae-00.2 -> 00-ab-76-94-69-00.3
[openflow.discovery    ] link detected: 00-ab-5e-70-a5-00.2 -> 00-ab-76-94-69-00.2
[openflow.discovery    ] link detected: 00-ab-76-94-69-00.2 -> 00-ab-5e-70-a5-00.2
// 4. Spanning Tree が起動
[openflow.spanning_tree] 6 ports changed
[openflow.discovery    ] link detected: 00-ab-76-94-69-00.3 -> 00-ab-f1-37-ae-00.2
[openflow.spanning_tree] 4 ports changed
[openflow.discovery    ] link detected: 00-ab-f1-37-ae-00.3 -> 00-ab-5e-70-a5-00.3
// 5. OVS-1の eth2 を接続して環状へ (interfaceを復帰)  
[openflow.spanning_tree] 2 ports changed
[openflow.discovery    ] link detected: 00-ab-5e-70-a5-00.3 -> 00-ab-f1-37-ae-00.3
[openflow.spanning_tree] 4 ports changed

しっかり動いている。唯一気になったのはOFCに接続していインターフェイスのMACアドレスが違っていることくらい。インターフェイスをプチプチ切っても端末間の通信はある程度維持。ワリと楽なのだ・・・VyattaでのSpanningTreeとかと組み合わせてみるのも面白い・・・かな。隙があったらやってみようと思う。完璧な実装を期待してはいないけれど実は多ベンダでのSpanningTreeってのもあまりやったことないもので。やってみる価値はありますぜ、と。

晴れてOpenFlowで遊べる環境というものが出来ましたが、何が出来るのか、とか何を基本に考えるかがまだ分からない。ということで、以下を参考に暫くは使い方なりコンポーネントを触って出来ることを確認。その上でコードを読むスタンスで行きましょう。ggr:"POX"+”書き方” とかしてもへぇ・・・だけで終わってしまう。

何気にWebインターフェイスを持っていたり。

追伸: 前回のPOX試した時にやたらとあがっていたDHCPのパケットはLinuxMicroのOpenvSwitchにて発射されていたしてたみたいで・・・どうも気を効かせてDHCPが全インターフェイス有効になっていた模様。即pkill。

実はOpenFlowについてはちゃんとした本を読んでいなかったり、出来ることをつまみつまみ見ていたのでまだ理解をしていない。そもそもOpenvSwitchとOpenFlowの関係であったりもイマイチ掴めていない。後からOpenFlowに対応したっぽくはある。てとりあえず、OpenFlowコントローラの制御下にあるとOpenvSwitchの設定よりそちらが優先される挙動は間違いなさそうです。

OpenFlow をまだ心で理解できていないので、手近なOpenvSwitchだけを少し触ってみる。

//初期化
# ovs-vsctl init
//仮想ブリッジ作成
# ovs-vsctl add-br   br0
//ポート割り当て
# ovs-vsctl add-port br0 eth0
# ovs-vsctl add-port br0 eth1
# ovs-vsctl add-port br0 eth2
# ovs-vsctl add-port br0 eth4
//vlan ID=100 (PVID) をつくてみる
# ovs-vsctl del-port br0 eth2
# ovs-vsctl del-port br0 eth4
# ovs-vsctl add-port br0 eth2 tag=100
# ovs-vsctl add-port br0 eth4 tag=100

//vlan ID100 のTrunk
# ovs-vsctl add-port br0 eth4
# ovs-vsctl add-port br0 eth4 trunk=100

なんとなく簡単に何か設定する分には直感的でやりやすい印象でした。

openflow と OpenFlow は違うのね・・・ 言われてみればそうだ

コマンド復唱と挙動の確認に昨日のL2フォワードを少し弄ってみる。

root@box:~# ovs-vsctl show
a66779ff-0224-40ef-89f1-0deb21b939db
    Bridge "br0"
        Controller "tcp:192.168.254.100"
        Port "br0"
            Interface "br0"
                type: internal
        Port "eth0"
            Interface "eth0"
        Port "eth1"
            Interface "eth1"
        Port "eth2"
            Interface "eth2"

こんな感じのものを3つほど用意。コントローラ無しでもPingが通ります。

さて今回はコントローラでL3のフォワーディングを実行。これも通ります。

# ./pox.py forwarding.l3_learning
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
INFO:core:POX 0.1.0 (betta) is up.
INFO:openflow.of_01:[00-00-ab-f3-41-02 1] connected
INFO:openflow.of_01:[00-ab-05-d3-88-00 2] connected
INFO:openflow.of_01:[00-00-ab-05-5d-02 3] connected
INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
INFO:forwarding.l3_learning:2884845826 2 RE-learned 0.0.0.0
INFO:forwarding.l3_learning:2869255426 2 RE-learned 192.168.0.10
INFO:forwarding.l3_learning:2884845826 2 RE-learned 192.168.0.30
....
...
..
.
^CINFO:core:Going down...
INFO:openflow.of_01:[00-00-ab-f3-41-02 1] disconnected
INFO:openflow.of_01:[00-ab-05-d3-88-00 2] disconnected
INFO:openflow.of_01:[00-00-ab-05-5d-02 3] disconnected
INFO:core:Down.

ところでこれはハブ/スイッチっぽい動作ですが、今日実行したものはL3フォワードによる疎通。ひょっとしてループ状にしてもブロードキャストストーム的な事が起こらないのではないだろうか？ということで以下のようなトポロジにしてみます。

ifconfig eth0 down; ifconfig eth1 down; ifconfig eth2 down;
ovs-vsctl init
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 eth1
ovs-vsctl add-port br0 eth2
ovs-vsctl set-controller br0 tcp:192.168.254.100

//3台整ったら
ifconfig eth0 up; ifconfig eth1 up; ifconfig eth2 up;

同じIPを何度も学習してPOXが落ちました。

ERROR:core:Exception while handling OpenFlowNexus!PacketIn...
Traceback (most recent call last):
  File "/root/pox/pox/lib/revent/revent.py", line 234, in raiseEventNoErrors
    return self.raiseEvent(event, *args, **kw)
  File "/root/pox/pox/lib/revent/revent.py", line 281, in raiseEvent
    rv = event._invoke(handler, *args, **kw)
  File "/root/pox/pox/lib/revent/revent.py", line 159, in _invoke
    return handler(self, *args, **kw)
  File "/root/pox/pox/forwarding/l3_learning.py", line 201, in _handle_PacketIn
    "input port" % (dpid, inport, str(dstaddr)))
TypeError: not all arguments converted during string formatting

うーん、いい考えと思ったのですが駄目みたいですね。インターフェイスを落とさないとループしましたし、PC1とPC2 (タイミングによる) だけ応答が出来る等不安定でしたし・・・まだサンプル動かして喜んでる程度では奇抜な事は出来なさそうです。

前回のGNS3の癖を掴んだので分かり易い導入記録を参考にして試してみます。(参考:OpenBlocks AX3でOpenFlowを試してみる) 構成は OpenvSwitch とPython製OpenflowコントローラのPOXにて。NOX (C実装)、Trema (Ruby実装) 等他にも色々ありますが、いずれ自分でも書くことにもなると思いますので、多少慣れているPython実装のPOXを選択。

最初の一歩目。イーサネットブリッジを作ります。

それぞれ適切なインターフェイスにIPアドレスを割り当て、openvswitchにてブリッジを構成。

Openvswitch にて

# 初期化
tc@box:~$ sudo ovs-vsctl init
# ブリッジ仮想インターフェイス作成
tc@box:~$ sudo ovs-vsctl add-br br0
# ブリッジに各イーサネットインターフェイスを割り当て
tc@box:~$ sudo ovs-vsctl add-port br0 eth0
tc@box:~$ sudo ovs-vsctl add-port br0 eth1

実はこれだけでブリッジが作成でき、SoftwareDefinedNetwork的な動きをします。裏で疎通確認用の端末がpingを送っていれば、add-port 以降疎通の確認が可能です。Openvswitchの設定だけでそれなりに高機能なスイッチとして動かせます。

続いてOpenflowコントローラを追加して、POXの制御下に居る事を確認します。

Openvswitchにて

//コントローラ追加
tc@box:~$ sudo ovs-vsctl set-controller br0 tcp:192.168.254.100
//設定はこのような感じになります。
tc@box:~$ sudo ovs-vsctl show
a66779ff-0224-40ef-89f1-0deb21b939db
    Bridge "br0"
        Controller "tcp:192.168.254.100"
            is_connected: true
        Port "br0"
            Interface "br0"
                type: internal
        Port "eth1"
            Interface "eth1"
        Port "eth0"
            Interface "eth0"

Openflowコントローラ用端末にて(FreeBSD8.4)

// githubよりPOXを取得
# git clone http://github.com/noxrepo/pox.git
# cd pox
// poxの実行　L2学習とフォワードのサンプルを使用
// (pox/forwarding/l2_learning.py)
# ./pox.py forwarding.l2_learning
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
INFO:core:POX 0.1.0 (betta) is up.
INFO:openflow.of_01:[00-ab-5e-70-a5-00 1] connected
INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
...

POXの実行をすると、openvswitchにて設定したホストからのコントロール接続を受け付ける。その後、転送を行うサンプルプログラムを実行する。何やらDHCPらしいパケットが常に飛んでいるようですが・・・pingは正常に動作していました。

POXコントローラを止めるとOpenvswitchのみの動作となり、これはこれでブリッジ的な動作を設定しているので、疎通確認のpingは一時的な切断が発生後、正常に通信ができます。さて、そんな中POXにて全く別なプログラムを読み込ませるとどうなるのか・・・読み込ませて疎通が出来なくなれば、POXにてスイッチ端末の挙動が変わったと考えて良いでしょう。

// テキトウにデバッグ用のをコントローラに読み込ませてみる
# ./pox.py debug-pox
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
// ここまで疎通を確認
INFO:core:POX 0.1.0 (betta) is up.
// ここから挙動が変化
INFO:openflow.of_01:[00-ab-5e-70-a5-00 1] connected
...

・・・ping 止まりました ∩（ ・ω・）∩ 。

この「おおっ」って感じはやってみないと分からないかもしれません。

先日のGNS3でSDNごっこをしようとしていたらどうにもうまく繋がらない。OpenflowのPOXコントローラがどうしても認識されなかったり。GNS3に登録した各Qemu用OpenvSwitchアプライアンスのイメージ自体は同じで、各設定の狂いは生じることは余程の事がないと起こらない。自分のコントローラが駄目という説もあるが、自分のコントローラが駄目な時は、他のアプライアンスも駄目であったりする。1対1とか個別だと問題は無いはずなのですが・・・そういえばインターフェイスの若い方がつながらないってことは出ていない。ということで、

とかやってみる事にする。

$ sudo ifconfig eth0 inet 192.168.0.254/24
$ sudo ifconfig eth1 inet 192.168.1.254/24
$ sudo ifconfig eth2 inet 192.168.2.254/24
$ sudo ifconfig eth3 inet 192.168.3.254/24
$ sudo ifconfig eth4 inet 192.168.4.254/24
$ sudo ifconfig eth5 inet 192.168.5.254/24

$ ping 192.168.0.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.1.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.2.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.3.10
13 packets transmitted, 0 packets received, 100% packet loss
$ ping 192.168.4.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.5.10
10 packets transmitted, 0 packets received, 100% packet loss

・・・どうも、このようなことが起こるようで。思えば律儀にコントローラは末尾の5番を使ってました。さて、アプライアンスの設定が原因かQemuの動作が怪しいのか。動作の怪しさで言えばシリアルコンソールのログオン画面が時と場合により、自動ログインされなかったりとか挙動が若干マチマチではありました・・・こうなるとどれも怪しく感じてしまう。とりあえずGNS3用QemuのNIC数デフォルト値は少なめの方が良さそうですね・・・時間をとられすぎました。

GNS3のQemuマシンは電源を切らないとLANケーブルの再配線ができないのが辛い。

20130718時点のGNS3用アプライアンスのお約束

■ Vyatta 6.6R1
User: vyatta
Pass: vyatta

■ LiSA 2.0.1
User: root
Pass: password

■ Openvswitch 1.2.2 installed on Microcore 4.0
User: tc
Pass:

お察しくださいなパスワードを一応記載

最近、ネットワーク的な事をしたく四苦八苦。良い機械は個人では用意もできないし、周りもどうぞと用意はしてくれない。風の噂で聞くPacketTracerもCisco専用であったり、そもそもCiscoアカデミーに所属しないと頂けない代物で個人でもつのはなかなか難しい。他に仮想的にネットワークを組んで設定等を試せるシミュレータはないものかと探してみたところ、GNS3 (Graphical Network Simulator) なるシミュレータがある模様で・・・早速導入。（実際のところ存在は知ってはいましたが、ネットワーク製品の試験だと結局ios等が必要になるって事でずっと保留していたり）

• GNS3 v0.8.x all-in-one をダウンロード
• Appliances -> Vyatta 6.x Qemu image をダウンロード
• Appliances -> Openvswitch 1.2.x installed on Microcore 4.0 をダウンロード(Qemu用)
• GNS3をインストール(一緒にWireshark/SuperPutty/Qemu等が入る)
• GNS3のQemu仮想マシン設定にダウンロードしたVyattaとOpenvSwitchを読み込ませる

(参照:GNS3+VirtualBox+Vyattaでネットワークのシミュレーション)

なんと、簡単に高機能なソフトウェアルータとSDN環境のシミュレータが簡単に出来上がってしまった・・・これはありがたい。実のところSDN検証用等で自分の家の仮想環境にある程度の大きさのLinuxを複製複製しては役割設定を毎回していたので非効率極まりない+そもそも環境を作るとどこかで躓いていたので非常に助かるところでした。ネットワークインターフェイスを用意してシミュレーション環境を実運用に組み込むことは出来ないけれど、いろいろ試すには十分。凄い時代になったものです。暫くはこちらをメインに色々遊んでみようと思います。

ところでVyattaをCisc○ライクと呼ぶのはどうなのだろう・・・触った感じあまり似ていないと思うのですが。CLIの操作がそれっぽいだけで、構文の雰囲気も、こうかな？って操作も効かないし、どうにも。

emerge: there are no ebuilds built with USE flags to satisfy
 ">=app-admin/eselect-php-0.7.0[apache2?,fpm?]".

 !!! One of the following packages is required to complete your request:
 - app-admin/eselect-php-0.7.1::gentoo (Change USE: +apache2)
 - dev-lang/php-5.4.17::gentoo (Change USE: -apache2)

どないせいと・・・

# USE=apache2 emerge eselect-php
Calculating dependencies... done!
[ebuild     U  ] app-admin/eselect-php-0.7.1 [0.6.2] USE="apache2% -fpm%"
[blocks B      ] <dev-lang/php-5.4.13-r1:5.4 
("<dev-lang/php-5.4.13-r1:5.4" is blocking app-admin/eselect-php-0.7.1)

('A`)ｳﾜｧ...

やるべきことがある日ほどコンフィグ作業が捗る。最近重宝しているSSL-VPNからのSquidによるProxy利用。AndroidでもiOSでもOpenVPNに対応したので、Squid周りももう少し整頓してみようかな、と思い、安全なSquid利用を出来るようにSquidの通信をClamAVにバイパスしてみる。

流儀はいろいろあるが、一発目に見たサイト「プロキシサーバーでウィルスチェック(Squid+SquidClamAV+ClamAV)」(iptablesの設定ではお世話になりました...) ではsquid.confからurlrewrite_programからsquidclamavを呼び出して実行している模様。なるほど。SquidとClamavは入っているのででは必要なSquidclamavを入れましょう。

# emerge -pv squidclamav
 [ebuild   R    ] net-proxy/c-icap-0.2.2  USE="berkdb ipv6 -ldap" 0 kB
 [ebuild   R    ] net-proxy/squidclamav-6.8  0 kB

# emerge squidclamav
...
Compiling...
...
 * To enable the service, you should add this to your c-icap.conf file:
 *
 *     Service clamav squidclamav.so
 *
 * And then this to squid.conf (for a local ICAP server):
 *
 *     icap_enable on
 *
 *     # not strictly needed, but useful for special access
 *     icap_send_client_ip on
 *     icap_send_client_username on
 *
 *     icap_service clamav respmod_precache bypass=0 icap://localhost:1344/clamav
 *     adaptation_access clamav allow all

なるほど、Gentoo的にはsquidclamavを使うにはc-icapを使いましょう、と。郷に入れば郷に従えということで警告の通りに設定するべきか。ICAPはInternet Content Adaptation Protocolとの事で・・・プロキシのフィルタ機能拡張用のプロトコルとの事です。どうにもフィルタ機能の一部が死んだ時にプロキシ機能全体が止まるのではなく、ある程度は無視してくれるらしい。Squid3系列以降から標準らしいし、汎用的で拡張性も良さそうなのでこの方法で決定。自分の環境はローカルからしか使えない閉じたSquid、閉じたICAPサーバ、そしてClamAV。これらをつなぐために以下の設定を行いました・・・というか、インストール後のメッセージ殆どそのままです。

# vim /etc/c-icap/icap.conf
...
Service clamav squidclamav.so #追記

## ACL & Control
acl localnet  src 173.230.147.180/255.255.255.255 192.168.x.0/255.255.255.0 
acl localnet6 src fe80::f03c:91ff:fe96:3cfd 2001:470:1f04:1a92::2
acl localhost src 127.0.0.1/255.255.255.255 ::1
acl all src 0.0.0.0/0.0.0.0 ::

client_access allow localnet
client_access allow localnet6
client_access allow localhost
client_access deny all

# vim /etc/squidclamav.conf
...
clamd_local /var/run/clamav/clamd.sock         # ClamAVのローカルソケット指定
redirect    http://ika.uso8000k.net/error.html # 検知時の転送先

# vim /etc/squidi/squid.conf
...
# Squid-Clamav
icap_enable on
icap_send_client_ip on
icap_send_client_username on

icap_client_username_header X-Authenticated-User
icap_service clamav respmod_precache bypass=0 icap://localhost:1344/clamav

adaptation_access clamav allow all

# /etc/init.d/c-icap restart
# /etc/init.d/squid  restart

にて、概ね設定完了。正常に起動してエラーもなく問題なし・・・に思われたがテストウィルスのEICARをそのままダウンロードしてしまう。何故だ。ログを見るとSquidで受け付けて正常にWebを見ることができているが一向にICAPに渡らない。ICAP設定はちゃんと書いているしエラーも出ていない・・・と思ってSquidのUSEフラグを確認したら USE=”icap-client” が必要だったらしい。Squidの再コンパイルしたら動きました。ところで、この挙動はICAP非対応の状態でSquidがICAP用設定を読めてしまっていた問題なのだろうか？それともSquidで読んでICAP関連でエラーが出ていたので、そのまま処理をSquidのみで動いていたのだろうか。後者だとわりと仕様の通りに動いていてすっきりします。図らずも一部の機能不全からの共倒れを確認できたことになります。

・・・マシン性能が一杯一杯なので少し大きめのZIPファイル落とすと辛いかも。

なんにしても
∩( ・ω・)∩

人生急に好きなことに対してやる気が出なくなることがありまして、私もここ数ヶ月そんな感じでした。いや、単に模型やゲーム等にに現をぬかしていただけなのですが・・・ さて久々にセキュリティ更新以外でサーバに対して何かをやってみようということで、手っ取り早いのでメールに対して信頼性を向上に試みようかと。

最近読みましたGoogleの脆弱性の記事の使われていた技術 DKIM (Domain Key Identified Mail) を導入。とりあえず、送り主のドメイン名が正当かをチェックするSPF (Sender Policy Framework) だけでやっていましたので併せてDKIMも入れてみようかというお話。 DKIMは送信時にヘッダに"DKIM-Signature:"を追加して、以下秘密鍵で暗号化されたを含んだ電子署名を送信。電子署名含みのメールを受け取ったサーバは送り主ドメインを管理するDNSサーバに問い合わせを行い、TXTレコードに登録された指定のホスト名として登録された公開鍵を使用して認証。

こんな感じのものを入れてみようかと。

パッケージインストール (いつものGentoo環境に)

$ sudo emerge opendkim
... 依存で mail-filter/libmilter

Postfixと組み合わせて使う予定をしているのでmilterなりが絡む。調べてみるとDKIMを使う場合にはdkim-milterを使うとのことでしたが、最近の流行に乗って opendkim なるものを使用。といいますか、dkim-milterが無い(ﾟДﾟ) そんな感じのパッケージ選択。 ほかはlibdkim/zdkimfilterもあるが、他MTA用であることとMASKされてることから、コレが今のところ正解かと。

インストール後、Portageの書置きの通りに鍵作成

$ sudo emerge --config
mail-filter/opendkim
Configuring pkg...

鍵の名前的なものと強度指定。ここ1を選ぶ。解読できる。俺知ってる。

Enter the selector name (default xxxx.uso8000k.net): mydkim
 * Select the size of private key:
 *   [1] 512 bits
 *   [2] 1024 bits
  Press 1 or 2 on the keyboard to select the key size: 2

(略)

DNS用 TXTレコードの内容が出力。

 
mydkim._domainkey IN TXT "v=DKIM1;=rsa;p=公開鍵";

ちなみにここには罠があり、

mydkim._domainkey IN TXT "v=DKIM1;k=rsa;p=公開鍵";

"k=rsa"と追記しないとキーとして働かないらしい。追記。

インストール時に /etc/opendkim へ opendkim.conf (設定ファイル) が、鍵生成時に mydkim.txt (DNS TXTレコード用テキスト)、mydkim.private (秘密鍵) のファイルが生成。 mydkim.txt の内容は自分が管理するDNSサーバ内自分のZONE不ファイルに適切に加工して追加。VPSについてくるWeb登録型のDNSについても、適切に加工すれば登録は可能。Linodeの場合は以下、

Name: mydkim._domainkey
Value: v=DKIM1;k=rsa;p=公開鍵;

ダブルクォートを消去。これでDNSの設定は終わり。以下確認。

$ nslookup -q=txt mydkim._domainkey.uso8000k.net
Server:         74.207.242.5
Address:        74.207.242.5#53

Non-authoritative answer:
mydkim._domainkey.uso8000k.net   text = "v=DKIM1\;k=rsa\; p=略\;"

Authoritative answers can be found from:
uso8000k.net    nameserver = ns1.uso8000k.net.

以降、opendkimの設定と、postfixのmilter設定

/etc/opendkim/opendkim.conf

# Syslog 
Syslog                  yes
SyslogSuccess           yes

Canonicalization        relaxed/simple

Domain                  uso8000k.net
Selector                mydkim
KeyFile                 /etc/opendkim/mydkim.private

SendReports             yes
ReportAddress           postmaster@uso8000k.net
#Statistics             /var/lib/opendkim/stats.dat

Socket                  inet:8891@localhost
UserID                  milter
PidFile                 /var/run/opendkim/opendkim.pid

/etc/postfix/main.cf

smtpd_milters     = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock

を追記。これで最低限の動作が可能。DNSの設定が反映されている事を確認の後、それぞれサービスの起動/再起動を行えば完了。複数ドメインを管理する場合はKeyFileではなくKeyTable記述を行う。

最後にDKIMの動作テスト: http://www.appmaildev.com/jp/dkim/

This email is an automatic response from AdminSystem DKIM verifier service (1.0.0.3).
The service allows email senders to perform a simple check of SPF, DKIM and DomainKeys.
It is provided free of charge, in the hope that it is useful to the email community.

We welcome any feedback you may have at <support@emailarchitect.net>.
Thank you for using the service.
AdminSystem Software Limited

============================================================
SPF result: Pass
============================================================
Domain: uso8000k.net
IP: 173.230.147.180

SPF Record: uso8000k.net
	IN TXT = "v=spf1 mx ~all"

============================================================
DomainKey result: none (no signature)
============================================================

============================================================
DKIM result: pass
============================================================
Signed by: harumaki@uso8000k.net
Expected Body Hash: 本文ハッシュ値

PublicKey: mydkim._domainkey.uso8000k.net
	IN TXT = "v=DKIM1;k=rsa; p=公開鍵;"

---Original Message Header---

∩( ・ω・)∩

参考URL

• Domainkeys and DKIM with Postfix
• CentOS5.5 Postfix で DKIM ( OpenDKIM ) に対応する