こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。
第6回トラコンでは15問の問題が学生の手によって出題されました!
今回は、私が担当した問題の内一つを紹介していきます。
タイトル:調子が悪いんでしょうか?
問題文
ある日、AWS内で弊社のWebサーバを稼動させることになりました。
ただしネットワークに割ける予算が少なかったために古いネットワーク機材を使用しています。
先日、本格稼動をする前に複数人で確認したところ、どうにも「見れるページ」と「見れないページ」が存在するようです。
また、状況によっては「見れないページ」も「見れる」場合があるそうです。
早急に原因を解明し、誤った設定内容を修正してください。修正後、報告もお願いします。
尚、変更するのはサーバのみでお願い致します。見れないページ : URL
ServerIPaddress : ****
認証情報 【ID】: ****
【Password】: ****FirewallIPaddress : ****
認証情報 【ID】: ****
【Password】:****
** 補足
問題を起こしている箇所を修正し、原因と修正内容を報告できれば対策を行えたものとします。*1
*1 どういう状態になるとゴールなのかを記載していなかった為。又、全ての環境でMTUキャッシュクリアの方法をMTUというワードを出さずに周知できなかった為、補足させていただきました。
問題解説
この問題は、問題文と各種設定から原因を見つけていく問題でした。
AWS関連の情報やMTUについて詳しく知っていればピンとくるかもしれない問題ですが、そうでない場合難しい問題となったかもしれません。
また、解く際にWiresharkを用いたりすれば、MSS値周りの情報からヒントを見つける事が可能でした。
キーポイント
- AWSのデフォルトMTU値が9001である
- FW(vyosA)でicmpが全て拒否されている為、PathMTUDiscoveryまで拒否されている(PathMTUDiscoveryBlackhole問題)
- 経路上のルータ(vyosB)のMTU値が800になっている
- 結果、サイズが800byte*2を越えるWebページだけが見れなくなってしまう
*2 実際には約600byte〜700byteくらい
解説
この問題では、一部Webページが見れない状況にありました。
その原因は、PathMTUDiscoveryが拒否されている事(PathMTUDiscoveryBlackhole)とMTUによってパケットがドロップしてしまう事でした。
まず前者についてですが、PathMTUDiscoveryはICMP type3 code4を用いMTUの低いルータ側から送信されます。
しかし、その先にあるファイアウォールがICMP全てをドロップしてしまう為、PathMTUDiscoveryが届かずデータの再送信が行われません。
その為、PCとAWS間のMSSが設定されたままパケットが送信され、途中経路のルータでパケットがドロップしてしまう状況が生まれます。
また、sshをすると通信の始めにクライアント側が大きいパケットを流すため、PathMTUDiscoveryがクライアント側に流れます。
そうすると、一時的にクライアント側のMTU値が800になるため、Webページを見れる状態になります。
しかし、これは恒久的な対策ではないため、これだけを解決策として報告した場合は間違いとなります。
今回、ファイアーウォールではなくサーバの設定を変更する問題となっているので、
サーバのMTU値を恒久的に800にあわせる設定を入れた事と、PathMTUDiscoveryBlackHoleについて触れていれば正解となります。
ただし、今回の状況から800というMTU値を推察するのは難しいだろうという事から、サーバのMTU値の設定はどの値にしていても間違いはないものとし、修正箇所と原因に気づければ正解としました。
解法
上記で大まかな解説は行っていますが、詳しい解き方については以下をご参照ください。
問題文からヒントを探す
この問題では、「一部見れないページがある」という現象が発生していました。
しかし、そのままではMTUが原因だとなかなか見つけられないかと思います。
なので、「AWS」や「古いネットワーク機材を使っている」というワードを文面に盛り込む事で、環境の違いを強調していました。
この文面から、環境によって引き起こされているトラブルではないか?と考えると解きやすかったかもしれません。
手元にある情報から探す
では、本当にページが見れないのか実行してみましょう。
(ブラウザでも確認はできますが、今回はcurlで実行してみました)
# curl -v http://hogehoge/ * About to connect() to hogehoge port 80 (#0) * Trying hogehoge ... connected * Connected to hogehoge ( hogehoge ) port 80 (#0) > GET / HTTP/1.1 > User-Agent : curl/~~~ > Host : ipaddress > Accept : */* >
上の結果から、コネクションは張れるけれどページが見れないという状態を確認できます。
また、この時のパケットをwireshark等で確認すると、3WAYHandshake時にMSSで9001という値が交換されています。
(これはWebServerへsshしifconfigする事でもわかります。)
そして、ssh時に帰ってきているパケットを見ると
「ネクストホップのmtuは800だよ」
というicmpパケット(PathMTUDiscovery)が来ているため経路上のMTU値も判断できるのです。
ここまで来ると、なんだかMTU怪しいなと感じませんか?
原因を特定する
さて、経路上のMTU値が低い事がわかりましたが、果たしてそれが原因なのでしょうか?
それを特定するためにはFWのコンフィグを見る必要があります。
FWには以下のような設定が入っていました。
・firewallをeth0にセット
・デフォルトアクションはドロップ
・許可するポート番号は80番と22番
つまり、HTTP(80/tcp)とssh(22/tcp)以外は通過できない状態にあったのです。
では整理も兼ねて、現状分かっている情報でトポロジ図を作ってみましょう。
このようになりますね。
それでは、これによってどのような事が起きるのでしょうか?
名前から先にお伝えすると、PathMTUDiscoveryBlackholeという現象が起きています。
PathMTUDiscoveryBlackholeとは・・・
経路上に異なるMTU値が存在していても、 Path MTU Discovery によって通信することができるようになりますが、適正なMTU値を伝達するためのICMP(type3 code4)パケットを送信元に送信しない設定や、途中の経路でICMPがフィルタリングされている場合には、以下のような問題が発生します。以下のような状態の事をPath MTU Discovery Black Holeといいます。
詳しくは以下のリンクへ
引用元 : http://www.infraexpert.com/info/5.2adsl.htm – ネットワークエンジニアとして
では以上の事を踏まえ、Webページを参照しようとした場合の流れを考えていきましょう。
Webページを参照する時の流れ
1.ユーザがWebページをサーバにリクエスト
2.3WAYHandshake時に交換したMSSに合わせてサーバがWebページを送信
3.通信経路上にあるネットワーク機器のMTU値が低いため、Webページを受け取れない
4.通信経路上のネットワーク機器(MTU800)がPathMTUDiscoveryをサーバに向かって送信する
5.FWによってPathMTUDiscoveryが拒否される
6.PathMTUDiscoveryBlackholeが発生し、Webページが読み込まれない
通信の流れを文章で書くと、このような形になっていたわけですね。
つまりここを解決できればなんとかなりそうですね!
対処する
そうなると、対処方法としては以下の二つが挙げられます。
・FWでicmpを通すように設定変更を行う (PathMTUDiscoveryのみ許可する場合はtype3code4のみ指定)
・サーバ側のMTUを経路上の最小MTU値に合わせる
このどっちかを行えば、今回の現象を回避できそうです。
ただし、問題文には以下のような記述があります。
尚、変更するのはサーバのみでお願い致します。
ということは、今回はサーバ側のMTUを変更すればよさそうですね。
それではサーバのMTU値ですが
1 |
/etc/sysconfig/network-scripts/ifcfg-eth0 |
今回の環境だと、このファイルに追加記述する事で変更できます。
追加する内容は以下になります。
1 |
MTU=800 |
これで保存した後に、インタフェースをアップし治す事でMTU値が反映されます。
1 2 3 |
ifdown eth0;ifup eth0 もしくは service network restart |
以上で、対応完了となります。
尚、以上のMTU設定に加え、PathMTUDiscoveryBlackholeについて触れていると完答となっていました。
まとめ
「PathMTUDiscovery問題」如何だったでしょうか?
序盤の方では「よく見る事」と「気づき」が重要になっていたので、難しい問題になったかもしれません。
そもそもこの問題自体、問題作成や検証にものすごく時間がかかった問題なので、私自体苦労して作っていました。
「MTUは暗黒大陸」なんて言われる事もあるようなので、この問題を通じてMTUの重要さとめんどくささが伝わればと思います!