最近 Asahi-Net で PoE じゃなかった。 IPoE で IPv6 が利用可能になった。僕は他にも hi.net で IPv6 を /48 ほど借りているので二つのセグメントが利用可能なのであります。贅沢だぁ;-)。
と、いうことで自宅のネットワーク環境を見直してみました。
IPv4/IPv6 のセグメントをそれぞれ表側・裏側と二つ用意したんですね。
構成図はこんな感じ。 (多少、端折っているf(^^;;)
Server-Zone と LAN-Zone があり、管理用 PC2 は両方のセグメントに到達性があるわけなんですが、実際に運用してみると非常に厄介。
例えば管理用 PC2 には LAN-Zone の 192.168.1.100 が、 Server-Zone には 192.168.22.100 が付加されているとして Server1 の Server-Zone 側の IPv4 に ping を打つと元リは LAN-Zone 側から戻ってきてしまう。ぐるっと回ってしまうんですね。
パケットの流れ的には以下のような感じ。PC2 のソースアドレスは 192.168.1.100 で出て行きます。
管理用PC2 の NIC1 -> Server2 の Server-Zone -> Server2 の LAN-Zone -> 管理用 PC2 の NIC2
ぐるっと一周の旅です。これがグローバルアドレスだと、ISP 側では『自分の管理してないアドレスからバケットが届いた。』ということで破棄されます。
あぁ・・。サーバにポリシールーティングの設定入れないと・・。 orz
FreeBSD の場合、 ipfw の fwd でも pf でも、バケットが届いた NIC から出ていく。って設定ができないんですね。
パケットが届いた NIC のゲートウェイアドレスに返す。って設定はできるようなんですけど、その場合はゲートウェイ経由で届いたパケットは送信元に戻っていくけど、同一セグメント上のコネクテッドな送信元には戻っていかない。まいったなぁ・・。
上記の構成図のうち Server1 が Linux (CentOS 6.9) の場合、以下のように /etc/rc.local に書くと良いです。
|
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1
route add と rule add を利用してポリシールーティングしてあげるとサクっと動作します。
最近の Linux のシステム管理者は default Gateway の設定はせず、ほとんど上記のようなポリシールーティングで設定を行い、セキュリティを強化しているようですねぇ。
FreeBSD の場合 ipfw の fwd では無理でした・・。僕にその知識が無いのかもしれないです・・。
なので、ファイアーウォールは ipfw だけど、ポリシールーティングの設定は pf でやるとこにしました。
以下が pf の設定です。 Server2 のは FreeBSD/amd64 10.3-RELEASE です。
/etc/pf.conf に記載します。記載したあとは service pf onestart したあとに pfctl -sa で確認できます。
|
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.20
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::3:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.20
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::3:1
これで FreeBSD の場合は IPv4/IPv6 共にパケットが届いた NIC と出ていく NIC が一緒になるかと思います。グルっと回って反対側の NIC から出ていくことはなくなります。
僕は pf についていまいち解ってないのですが、 pass out on vmx0 route-to のオプションで (NIC Gateway) の設定があるのですが、この場合は vmx0 の 192.168.22.1 なゲートウェイアドレスに転送するよ。って設定ぽいですね。その場合、同一セグメント上の送信元、俗に言う、コネクテッドなホストには届かないんでないの? って気がするので (NIC Gateway) の記述ではなく () をはずして NIC のみを記載しています。
1).コネクテッドなホストと通信ができて、ゲートウェイの先のホストと通信ができない設定
|
2).ゲートウェイの先のホストと通信ができて、コネクテッドなホストと通信ができない設定
|
IPv4 の LAN-Zone なアドレスは外と通信することが無いので 1). の設定で十分な気がします。
IPv6 アドレスの場合、LAN-Zone は守りたいので 1). のほうが良いかな。
こーいうのを意識せずに、ゲートウェイの先のホストとコネクテッドなホストの両方と通信できる設定ってできるのかしら? その点 Linux は良い感じに動作していると思うんですけども。
ポリシールーティングの設定の場合、入ってきた NIC の先の Gateway に返す。ってのはウェブでまぁ、ほどほど見かけるのですが、僕から言わせてもらうと『入って来た NIC から出ていってくれてるだけで良いよ。』ってのが素直な感想なのだけど、そーは行かないのかな?
設定が完了したら pfctl -sa してみたり tcpdump -i vmx0 で確認してみると、パケットは入って来たポートから出ていくし、コネクテッドなホストとも無事に通信ができています。まぁ、この設定でヨシとしておきましょう。
あと、今回の検証のために FreeBSD の VRF の技術でもある setfib を試しましたが IPv6 が使えないのね・・。
そして、fib ごとにルーティングテーブルが個別になると思うんだけど、どうして別の fib のルーティング情報も見えるんだろう? fib はインターフェースとリンクしなくて良いのかな? 不思議だ・・。
|
(fib: 0) 側に 192.168.1.0/24 のルーティング情報が乗っていたら意味ないし、 (fib: 1) に 192.168.22.0/24 の情報があったら、ダメなような気がするんだけど・・。 ue0 から入ってきたパケットは wlan0 に抜けていってしまうと思われる・・。
setfib って、二つ (fib の数だけ) のルーティングテーブルを持つことができる。って機能ではないのかしら?
ルーティングテーブルがこんな具合になってくれていると多分 pf によるポリシールーティングは必要ないのではないか。と思われます。
|
[…] と、いうことで前回同様、今回も pf を利用します。 […]
[…] ちょっと前のエントリで FreeBSD のポリシールーティングについて書きました。そのときは FreeBSD においては pf で設定しました。そして、他のやり方がないのか検討し、その記事の下のほ […]
fib: 1 にも余計なルーティング情報が入ってしまうのは、もしかしたら `net.add_addr_allfibs=0` で解決するかもしれません。
参考) FreeBSD – multiple routing tables
[…] って、 if_vmx.ko は fib に対応したのですが、そこにバグがあるようです。fib については簡単にですが以前書いていますので、そちらを参考にして頂ければと思います。僕的には ubuntu の VRF […]
タイトル FreeBSD の VRF。 よりリンクがあります。
https://running-dog.net/2021/10/post_2489.html
[…] このブログでは何回か VRF について書きました。 FreeBSD の VRF、ubuntu の VRF など。 FreeBSD のポリシールーティングのネタも書いたこともありました。 […]