初めまして。記念すべき、初投稿になります。
今回は、内部から外に向けた通信を実現するにあたって、ＮＡＴとルーティングとＡＣＬに
関連したトラブルについてお話出来ればと思います。
アプリケーション技術者の方も参考になるかと思います。
それでは、通信テスト時にトラブル原因になるのを説明していきたいと思います。
Ⅰ. 設定漏れ
これは、主にネットワークエンジニアの技術不足やアドレス要件理解不足が原因です。
（例１）outside nat を設定したけど、戻り通信用のルーティング設定が足りてない。
→これは、ＮＡＴと、ルーティングの処理順序を理解できていない所が起因しています。
詳しくは、以下を参照ください。
https://www.cisco.com/c/ja_jp/support/docs/ip/network-address-translation-nat/6209-5.html
なお、NATって、色々なＮＡＴがあります。
SNAT ( Source NAT ) と呼ばれ、inside NAT outside NATがあります。
NAPT(Network Address Port Translation )もしくはPAT
企業だと、情報系に、NAPTを使って、サーバ間同士や外部から社内サーバにアクセスする通信にはSNATを使われているのが多いかと思います。
（例２）ＡＣＬの設定が間違っている。
→通常のＡＣＬに加えて、インターネットＶＰＮを設定している場合、ポリシーベースＶＰＮだと、トラフィックを定義するＡＣＬも注意する点になります。
ほかにもあるかもしれませんが、今回は割愛します。
Ⅱ. テスト時の投げ先の間違い
これは、アドレス設計後、主にネットワーク技術者と、アプリケーション技術者のコミュニケーション不足（テストの仕方の伝達や、何処から投げるのか）が起因する事が多いです。
①どのサーバＩＰからテストする。（発信元ＩＰ）
②どのＩＰに向けてテストする。（宛先ＩＰ）
→これがくせ者で、外部のクラウド側のサーバのグローバルＩＰに投げるという事をして
失敗するとかがありますが、アドレス枯渇の問題考慮して通常はＳＮＡＴを設定しているので、
例えば以下の例の場合
外部のサーバＩＰ = 5.10.100.5
ＮＡＴ設定で、以下を紐付け＝ 172.16.100.10
上記のアドレスでＮＡＴをCisco機器で設定した場合。
ip nat outside source static 5.10.100.5 172.16.100.10
ip route 172.16.100.10 (next hop先のルータＩＰ)
となり、サーバエンジニアは、172.16.100.10 を宛先にしてテストしなければいけません。
Ⅲ. テスト時の方法が間違い
これは、Linux サーバなどでテストをする時によく起こる問題です。
①traceroute を投げたら拒否られた。
この場合、デフォルトがＵＤＰを使用しているという事が抜けている事が原因の場合が多いです。
基本的なコマンドすぎて、コマンドの動作を明確に理解せずオプション情報を見落としていたりする人が多いかと思います。
②ポート番号指定のテストがわかない。
これは、telnetポート番号指定という方法がありますが詳しくは割愛します。
【まとめ】
ＮＷ機器の設定は、ネットワークエンジニアの責任ですが、テスト時の宛先ＩＰの決定、テスト方法については、アプリケーション技術者の責任になるため、対立せず担当者はネットワークエンジニアと主体性を持って明確に意識共有する事が重要です。
プロジェクトに時間の余裕のある場合であれば、さほど問題になりません。ですが、短納期などが要求される場合、事前にネットワークエンジニアとしっかりと意識を合わせてテストに挑まれるのがよろしいかと思います。
ネットワークエンジニア側は、ルーティング、ＮＡＴ，ＡＣＬ，ＶＰＮ、というパケットの処理順序をしっかり把握、さらに既存経路上で障害とならないよう経路上の外部ルータまで通信が到達出来るように設定されているか（忘れがちなL2設定も）などをネットワーク全体を考慮して設計構築をしていく必要があります。
入会申込
ログイン
