何か決めなきゃ駄目ですか。



俺が決めたら、貴方はどうするんだい。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PageTop

pfのNATreflector

軽くメモ。

pf on FreeBSDでヘアピンNATっぽいことをするための設定。
と言っても、場当たり的だからあんまりやらないほうがいいよ。という話。

正確なことはこっち。
http://www.openbsd.org/faq/pf/rdr.html

一般的なNAPT環境だと、リダイレクト(ext -> int)を書いて終わりだけど、
内側からWAN側アドレスに向かって接続しようとするとRSTの嵐。
ならヘアピン用の接続は先にNAT書いておけばいいよね?

いや、正直言うとあんまり理解できてないです。


1.LAN側アドレスで応答して、以後仲介。

www_server = "192.168.122.120"
rdr on $int_if proto tcp from ($int_if)/24 to $ext_if port 80 -> $www_server
nat on $int_if proto tcp from ($int_if)/24 to $www_server port 80 -> $int_if



pf_nat_reflector.png

pfctl -ss | grep :80 | grep ESTAB
all tcp 192.168.122.120:80 <- 124.102.57.170:80 <- 192.168.122.53:3502 ESTABLISHED:ESTABLISHED
all tcp 192.168.122.53:3502 -> 192.168.122.101:56403 -> 192.168.122.120:80 ESTABLISHED:ESTABLISHED





2.WAN側アドレスで応答して、以後仲介。こっちの方がRFC4878的には正統派?

www_server = "192.168.122.120"
rdr on $int_if proto tcp from ($int_if)/24 to $ext_if port 80 -> $www_server
nat on $int_if proto tcp from ($int_if)/24 to $www_server port 80 -> $ext_if



pf_nat_reflector_002.png

pfctl -ss | grep :80 | grep ESTAB
all tcp 192.168.122.120:80 <- 124.102.57.170:80 <- 192.168.122.53:3491 ESTABLISHED:ESTABLISHED
all tcp 192.168.122.53:3491 -> 124.102.57.170:63257 -> 192.168.122.120:80 ESTABLISHED:ESTABLISHED





多分あってると思うけど、ワカンネ。

そして、ここで初めて1810G-24のミラーリング機能を使った。
マジで宝の持ち腐れだな・・・。

スポンサーサイト

PageTop

IPv6とFlets

クライアント1台1台でPrefix-Policyを設定するなんて面倒なことこの上ない。
だったら、ゲートウェイに透過型のproxyでも置いてやれば解決するだろ、と勝手に思っていた。

静的に設定するなら、適当にsquidをインストールして、

 /usr/local/etc/squid/squid.conf


acl to_flets dst 2001:c90::/32
tcp_outgoing_address 2001:c90:XXXX:XXXX::1 to_flets

のような形で書けばいい。
(もちろん、デフォルトゲートウェイ、2001:c90::/32のルートを既に持っているとして、だ。)
参考。

# netstat -rn
default ng2 ULS ng2
2001:c90::/32 fe80::212:d9ff:febd:391b%vge0 UGS vge0



とはいえ、squid3.1はIPv6対応だー。

と、思って適当にdocumentを読んでいたら、

# intercept Support for IP-Layer interception of
# outgoing requests without browser settings.
# NP: disables authentication and IPv6 on the port.


と書かれていて絶望した。


じゃあ、やっぱりプロキシの自動設定ファイルを書いて配布するか…。
安定しなさそうだから、出来れば透過型がいいんだけど、対応を待つか…。
(自分で書くという選択肢は無い。)


そういう話。

PageTop

あれ?

(prefixpolicyを設定しないという意味で)何も考えずにフレッツv6と共存してると、
ロンゲストマッチ的に考えて、大体フレッツv6のアドレスが勝つ。
# BSDルータ + WAN/LAN bridge + radvdな環境で

というのが、所謂経験則だったのだが、

windows7を同じ環境に放り込んだら、何故かグローバル側が勝つようになってる。
あー…寝る前に変なことに気づくんじゃなかった。

どっかにそれらしいこと書いてあるっけ。
だめ、寝よ。

PageTop

16port↑GigaSWの話。

ミラーリングはとりあえず必須。
できればdestポートを除いた全ポートを監視対象にできたら嬉しいけど、
まぁ4ポート位でも我慢しようかな…(と、DELLのPowerConnectのページを見ていて思った。)


I/OのETG2-SHV16N
PlanexのSW-0214G
PlanexのSWP-0412G2
HPのProCurve1810G-24
DELLのPowerConnect 2816

HPは高い。
それ以外は似たり寄ったりな価格。
価格ではPlanex ≧ I/O > DELL >>>>> HP。
機能ではHP > DELL > Planex ≒ I/O。(あくまで多機能かどうか、って意味で)
性能面は不明。
使ってみたい、って意味じゃやっぱりHPなんだけど、高いなぁ…。



以下除外。
Buffaloはミラー対象ポートが1つだけなので除外。あと安くなってねぇ。
Coregaは生産終了で除外。割と見当たらない。
D-Linkは高すぎ。機能良好。性能不明。
NETGEARはちょっと高い。機能微妙。性能に不安有。

PageTop

Filteringしよう・・・?

FWのFiltering方式の違いって、境界が曖昧過ぎていまひとつ。
今のところこんな風に考えてるのだけど、結局実装依存だろう。


Static Filtering
最も一般的。
WAN→LANへ80/TCPのパケットを通過させると書けば、その通りに動く。
その代わり、上記のようなルールだけ書くと戻りパケットが通らない。
書きたいなら、LAN:80→WAN:anyを通過させるように書かないといけない。
ついでに、制御ポートと転送ポートが別にあるFTPのようなプロトコルは、
転送用ポートと送信元ポートの範囲を狭めたり、その範囲を全部穴開けないと動かない。
設定が至極面倒な上に、数が増えると穴だらけになる。


Dynamic Packet Filtering
Static Filteringじゃどうしようも無いので、動的にルールを追加することにした方式。
Static Filteringで許可したパケットの応答パケットは通過するように自動設定する。
先の例で言えば、WAN→LAN:80にアクセスしてきたら、
LAN:80→WANに対するパケットは通過するように設定する。
これで、手動で書くルールの数は1つで済む。
しかも中には賢い奴がいて、FTPのPORTコマンド等の中を覗いて、
自動的にPORTに合ったポートの許可ルールを生成してくれる。
でも、Stateは保存していないので、TCPで言うとSYNが通過した瞬間に逆向きルールが出来る。
こうなると、アドレスとポート番号さえあわせればパケットが通過し放題になってしまう。
構わないときもあるけど、困る時もある。そういうもの。
FTPって書いたけど、対応プロトコルは実装でマチマチだから確認しましょう、という話。


Stateful Packet Filtering
Dynamic Packet Filteringと似たようなもの。
許可したパケットの応答パケットは通過するように自動設定してくれる。
State Tableにセッション情報を乗っけて、パケットとState(ESTABLISHとか)を比較する上に、
Sequence番号とかFlag等も保存してくれるから、正しいシーケンスしかパケットが通過しない。
具体的に言うと、TCPセッションが確立した後、全然違うSequence番号のパケットが
飛んできても、叩き落してくれる。(まぁ、ノードが受け取っても大体は捨てるんだけどさ)
SYNの後にACKが飛んできても落としてくれる。
その代わり、FTPとかそういう小難しいことは出来ない。


Stateful Packet Inspection (同Stateful Inspection (c)CheckPoint)
Dynamic Packet FilteringとStateful Packet Filteringの複合型。
シーケンスも見るし、パケットの中身も見る。
SYN投げてSYN/ACKじゃないのが返ってきたら蹴ってくれるよ!...って聞いた。
ICMP Request送信して、IDの違うReplyが戻って来たらゴミのように落としてくれるさ!...多分。
DNS Cache Pisoningとかも大半は落としてくれるよ!...きっと!
そういう超強い子。
実装依存。



と、こんな雰囲気だろうか。

あれだよね、Linuxで大人気のiptables/netfilterのページに行くと、Stateful Packet Filteringに
Module噛ませてh323のStateful Packet Inspectionとか出来るように見えるよね。
俺の適当な意見とかいいから、本当かよ、って人用のLink:Netfilter Extensions HOWTO
むしろ俺用。

BSDだとどうなってるんだろう・・・正直pfとかipfwとか良く分かんなくて・・・モニュモニュ。



なんかその・・・決定的に間違ってたらこっそり教えてくれないかなぁ・・・。






でも、ボクが最終的に言いたいのは、突き詰めて考えた分類は個を示すのみなのだから、
良く分かってない人の分類ほど酷いものは無い、ってことなのかもしれない。
分類学とはマクロな視点とミクロな視点の両方がなければ成り立たないし、
学問において優れた人は違いを見抜くことに長けている。
個の寄せ集めにつけた名前に、分類上の価値なんて無いんじゃねーかな。
お偉方はすぐそういう分類したがるけどね、よくわかんねーからそうしたがるんだろうかね?
ってことはギャルにキモオタの分類させたら人種の細分化が凄いことに!
いやまてよ?全部キモオタって分類になっちゃうのかな?
でもどこがキモイのか上手く表現してくれさえすれば、更なる分類のカテゴリが・・・
あ、俺キモイな、これ。

PageTop
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。