レス数が1000を超えています。残念ながら全部は表示しません。

初心者もＯＫ！ FreeBSD質問スレッド その18

964 ：932 ：02/06/20 05:51

ipfw+natd、どうしても理解できなかったので、ipfwでlogをとりつつ、natd -verboseでnat変換をモニタしてみました。

>>936
言い切られたので自分が勘違いしてるんだとおもってけど…やっぱり当初の予想通りnatdにdivertされたパケットはnat変換後ipfwに戻る際にdivertされた位置の次のルールからマッチングが開始されてるようですよ。

add 100 deny log all from any to 192.168.0.0/16 recv tun0
add 200 divert natd all from any to any via tun0
add 300 allow all from any to 192.168.0.0/16 recv tun0
add 400 allow all from 192.168.0.0/16 to any

このルールでnat変換後、ルール100でパケットが落とされていたと思っていた問題はipfwの動作を見落としていました。
ルール200のnat変換後、ルール300でtun0から入るパケットは受付けていました。(logで確認)
その後、eth1(=sis1)からlan内に送られる際に再度ipfwを通るので、そのときにルール100にマッチして落とされていました。
一度受付けたパケットにもかかわらず、送り出されるときには再度正当性が確認されるんですね…。


>>938
調べてみたんですがnatの場合にestablishedを通さないといけない理由がわかりません。
add allow all from 192.168.0.0/16 to any
このルールがnatdへのdivertより前にあるとソースアドレスが外にでていっちゃいますけど、natdにdivertした後に置いてあると問題ないように思えます。
実際ちゃんとアドレス変換されてるのがモニタできました。
establishedってコネクションを張るサービス毎にrecvルールを書かなくても良いとか、コネクション中のパケットを優先的に受けるようにする為の物じゃないんですか?


>>957
しばらくppp(-nat)+ipfwでやってましたがポートリダイレクトのやり方が探せなくてnatdに逃げてました。
今調べたらppp(-nat)でもnatdとほとんど同じですね(^^;
natdの動作もだいたいわかった(つもり)なのでppp(-nat)に戻ろうかとおもいます。

read.cgi ver5.26+ (01/10/21-)