スポンサーサイト

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

ネットワーク設計の覚書

今回はいつもと全然関係ないことを書きます。
私はネットワークエンジニアとして普段、設計業務をやっていますが
トラブルが起きることもあります。

マイナーブログですが、同じような業務をなさっている方の一助になれば幸いです。

すべて実際にあった案件をもとにしていますが
顧客が特定できそうな部分は伏せています。
ネットワーク機器
 
行きと戻りでNATするルータが異なる際のFTPの動作

LAN--insideNAT--RT1-outsideNAT--WAN(Main)--RT2--insideNAT--L2SW#1--LAN2
-----------------|outsideNAT----------------|outsideNAT
LAN--insideNAT--RT3-outsideNAT--WAN(Backup)--RT4--insideNAT--L2SW#2--LAN2



上記構成で下側がLAN側は
スタティックルート+HSRP
WAN側とルータ間リンクはOSPFを流して
メイン系WANを優先的に経由するように設定しています。

NATはinside-sourceNATを使用しています。
図中のinsideNATがinsideインタフェース、outsideNATがoutsideインタフェースです。

ここでメイン系のWAN網に障害が起きた時
行きのパケットはRT1→RT3→RT4→L2SW#2
戻りはL2SW#1→RT2→RT4→RT3
という経路を辿ります。

inside-sourceですので
行きはRT1とRT4でNATされ戻りはRT2とRT3でNATされます。

ここで両端(LAN-LAN2)間でFTPを実行したところコマンド入力がNGでした。
FTPは標準FTPです。

同一ルータでNATされた場合、データ内のアドレス変換によって
データ長が変更になっても、戻りのパケット受信時にSeq番号、Ack番号
を元にデータ長に合わせて調整します。
しかし、このように戻りのパケットを異なるルータで受信した場合
Seq番号、Ack番号の調整が必要であることを判断できずそのまま転送します。
これによって、FTPサーバ側で送信パケットと受信パケットのシークエンスにずれを検知し
正常に通信できなくなること(コマンド入力に応答がない等)があります。

そこでNATをoutside-sourceにし、ルータ間リンクをinsideインタフェースにして解決しました。
outsideなので行きも戻りもRT3,RT4のoutsideでNATされることになります。
HSRPのrtr機能(ルータ間でpingを定期的に実行して応答が無くなったら切り替える)
をメイン系ルータに設定して
対向側のインタフェースが死んだら切り替える(行きと戻りの経路を同一にする)
という設定も考えましたがこの時はIOSの変更が必要になったため断念しました。

余談になりますが最近の15.0以降のIOSバージョンではHSRPの
インタフェーストラッキング設定自体がrtrのような設定になっています。

NATの処理順序について記載されたCiscoのドキュメントです。
http://www.cisco.com/JP/support/public/ht/tac/100/1008335/5-j.shtml

HSRPの拡張機能についての設定例です。
このサイト分かりやすいですね。
http://www.smartnetworks.jp/2006/02/hsrp_5_ip.html

CiscoルータにFirewall機能を載せる際の注意点

CiscoルータではIOSのフィーチャセットによっては
ルータにFirewall機能を載せることが可能です。
これの機能のことをCiscoではCBACと呼称します。

LAN--ルータ--WAN(インターネット網)

上記のような単純な構成を思い浮かべてください。
この際に
1.インターネット網側(以下WAN側と記載)からの通信は全て拒否
2.LAN側からの通信は全て許可
としたい場合、単純にインターネット網側からを全て拒否とする
ACLでフィルタリングすると一点問題が生じます。
それは内部発信の通信の戻りパケットを全て拒否してしまうということです。

上記文の設定イメージはこんな感じです。
機器は仮にCisco1812だと思ってください。
WAN側インタフェースがFa0
LAN側インタフェースがFa1です。

LAN側インタフェースに設定するACL
access-list 100 permit ip any any any
interface FastEthernet 1
ip access-group 100 in

WAN側インタフェースに設定するACL
access-list 101 deny ip any any any
interface FastEthernet 0
ip access-group 101 in


これをACLで単純に再現しようとすると
WAN側から許可する通信を1行1行記述しなければなりません。

この場合方式としては
ACLのEstablished機能を使用することによって
TCPのセッション管理を実施することも可能ですが
それではUDPのセッション管理ができません。

したがってこの機能は
1.全ての通信要件を把握できていない
2.LAN側から許可した通信の戻りを許可したい
3.Firewallを別に置く費用がない
という条件がそろった際には便利です。

ただしOSレベルで載せる機能であり
ルータのパフォーマンスには当然影響を及ぼします。

ルータはあくまでルーティングをする機器ですので
その点は考慮が必須となります。

もう一点この機能には
フラグメントしたパケットをドロップさせてしまう
という仕様上の欠点があります。

特に通信を暗号化させている場合には
mtu、mssを最適値に設定してフラグメントを
防ぐよう留意しなければなりません。

CBACの設定例が載っています。
http://amamiya1980.blog93.fc2.com/blog-entry-34.html

余談になりますがYamahaルータではダイナミックACLというものがあり
こちらで似たようなことができます。
Yamahaルータはあまり触ったことがないのでなんとも言えないのですが。
http://www.rtpro.yamaha.co.jp/RT/docs/firewall/index.html

コメント

何がかいてあるんだか全然わからんぞ。。
2010/ 11/ 23( 火) 21: 05: 47| URL| あづち# -[ 編集 ]
 
> 何がかいてあるんだか全然わからんぞ。。
要するに腹が減ったら飯を食えってことです。
2010/ 11/ 24( 水) 21: 17: 56| URL| ランボー怒りのサービス残業# -[ 編集 ]
 

コメントの投稿

  • URL
  • コメント内容
  • password
  • 秘密
  • 管理者にだけ表示を許可する

トラックバック

トラックバックURL: http://undersiege.blog112.fc2.com/tb.php/21-d29d64a4
ブログパーツ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。