「『URLに繋がらない！』その時NWエンジニアはどう動く？プロキシ・FW・証明書のトラブルシューティング術」
今回はネットワークをやるなら避けては通れない通信エラー・通信制御に関してお話ししていこうかと思います。割と社内SE向けの話です。
はじめに
通信制御自体はいろいろな箇所で行われていますが、この記事では、多くの企業で実施されている内部⇔外部通信の制御についてお話しします。
アクセス先に繋がらないと言われた！そんなときは。
最初期：初歩的な切り分け
情報が少ない場合は、まず以下をユーザーに確認してみましょう。
・特定の端末のみが繋がらないのか
・特定のURLに対してのみ繋がらないのか
どの端末からも繋がらないのであればその接続先か経路に問題がありますし特定の端末からのみ繋がらないのであればその端末内の接続設定に何かしらの問題があることが多いです。
考えてみれば当たり前ですがたったこれだけでざっくりとですが端末単位、接続先単位で問題が起きているのかを切り分けることができます。
・エラー画面を確認する。
これも当たり前ですが接続できないエラー画面には、原因を特定するための情報が表示されていることが多いです。
ブラウザからの接続であればブロック画面、コマンドラインであれば返されるエラーを必ず読みましょう。
ここでSSLエラーが出ていたら何らかの証明書エラーの可能性が高いですし自社のグローバルIPに対して「Access Denied」などの画面が出ているのであればアクセス先側のIP制限です。
ここまではただの切り分けです。通信制御の部分に関して触れてもいないです。
初期その2：もうちょっと切り分けする。
上の確認で端末設定ではなさそうなことが切り分けできたら続いてはもうちょっと進めて経路の通信ログからの確認です。
とりあえずアクセス先のURLはあると思いますがアクセス元のIPやアクセスを試行した時間帯などをもらいましょう。
見るべきものは社内にあるプロキシサーバやファイアウォールなどのログとなるかと思います。
機器により確認の仕方は違いますので詳細は省きますが最低限ブロックされていないか、通信が落ちていないかは見ましょう。
もしブロックされていたら一旦そこを解消しなければなりません。
また通信ログがなければそこにくるまでの間に何らかの理由で通信が落ちているかもしれません。
経路を確認しましょう。
ブロックされていないようなログがあるのであれば経路は問題ないとして次へ行きましょう。
中期：本当にその通信は通していいのか。
ではブロックが確認できた場合、(これも機器によりけりですが)設定として許可をすることは恐らくそう難しくはないと思います。
ですがブロックの原因はしっかりと確認しなければいけません。
本来通るべき通信が設定ミスなどで通っていなかったのであれば通すことに問題はないでしょう。
ですがそれがもし何らかの理由で不正なアクセス先として検出されたものであれば？
必ずアクセス先の安全性の裏付け、承認やアクセス許可を社内で受けているかを確認するようにしてください。
後期：通す
アクセスしても問題ない裏付けが取れれば通信を許可しましょう。
ただ元々ブロックされていない通信は当然ながらここでは対応できません。
・そもそも通信が来ていない⇒送信元の端末での設定と経路の設定を確認
・通信は到達しているもののエラーとなる場合は、送信先側やその間の機器で制御されていないか
などといったことを再度確認しましょう。
またよくありますが名前解決ができていないとか想定したIPになっていないといったこともたまにあります。
観点を変えて確認してみるとよいでしょう。
まとめ
一概にURLを通すといっても様々な対応が必要です。
手順や対応を少し間違えると対応しても通らなかったり通してはいけない通信を通してしまったり・・・といったことになりかねません。
そういったことを防ぐためにもしっかりと現在の状態を把握しながら対応を行うといいでしょう。
この記事がその一助となれば幸いです。
