最初に結論を書くと、Proxmoxの機能として実装されているファイアウォールのうち、
ホスト・ゲストのファイアウォールが無効化していても、
ゲストの仮想NICに適用するファイアウォールが全許可でも適用している状態では、
3ウェイハンドシェイクが出来ずTCP通信が遮断されてしまう事象だった。
………
通常状態は次の様に経路制御しており、
HSRPでActiveになるルータは対にさせつつMEDを使って実トラフィックを迂回させていた。
つまり、ルータ間の渡りを使う事で迂回させるオーソドックスな構成となる。
その状態でHSRPのActiveでeBGPピアをダウンさせたら、Server-AからServer-BへのSSHは出来た。
HSPRのActive・Standbyが切り替わっていないが、
eBGPピアダウンでは切り替わらない様にしているのでNW設計上は正常動作となる。
この状態でServer-BからServer-Aに対してSSHしようとした所、SSHの応答が返ってこなかった。
pingは問題なく返って来るのでARPは問題なく、NW経路の観点では問題無い事が確定。
そうなると、L4以上の何処かが問題になるのでファイアウォールあたりが怪しいと踏んだ。
そもそも、ファイアウォールは全許可に設定していたので一旦置いときつつ、
切り分けの為にHSRPのActive・Standbyを切り替えてみたが通信が出来なかった。
仮想・物理を経由しているのでMTUに問題があるかと思い設定変更も試したのだが解決出来ず、
Proxmox上で何か起きていると判断してパケットキャプチャしてみた。
その時、Proxmoxで不思議な事が起きた―――
Proxmoxをインストールしている物理サーバのNICまでは通信が正常に来ているのだが、
ゲストOSの仮想NICにパケットが転送されておらず、物理NICで通信が破棄されていた。
しかし、上の方に書いた通りゲストOS宛のProxmoxファイアウォールは全部許可しており、
通信破棄されている理由がわからなかった。
………
という事で、Proxmoxでtcpdumpやstraceして挙動を確認しつつ、
コミュニティーに情報があるか確認したらProxmoxのNIC挙動について書かれていた。
ProxmoxでゲストOSを起動すると “tap100i0” の様にIDに紐づく仮想NICがホストOSで作成され、
物理NICのパケットをゲストOSの仮想NICにブリッジして通信させる挙動らしい。
という事は、ゲストOSや仮想NICのファイアウォールが紐づくならこの部分なのと、
物理NICから仮想NICにパケット転送出来ていない所が鍵になると考えた。
NWの話となるが今回は意図的に非対称ルーティングになっている都合上、
3ウェイハンドシェイクでは “SYN+ACK” がいきなりProxmoxに投げつけられる形となる。
Cisco ASAなどファイアウォールアプライアンスでは、
SYNフラッド攻撃やSYN/ACKリフレクション攻撃の対策として、
通信許可しているのに “SYN+ACK” だけのパケットに応答しないモードがあるのだが、
まさにコレと同様の事象が今回のProxmoxでも起きているのでは無いかと予想した。
という事で、ゲストOSの設定を全て確認した所、
ゲストOS本体のファイアウォールは無効化されているが、
ゲストOSの仮想NICでファイアウォールが全許可状態だが有効である事を確認。
コレを試しに無効化してみた所、Proxmox経由の非対称ルーティングも出来る様になった。
非対称ルーティングをしている時にSSHが繋がらない事例は聞いたことがあり、
事例としてもアプリケーション問題が大半だった。
そんな中、ルータで通信を遮断している今回の状態は想定外だった…
そもそも、インターネットの世界だと非対称ルーティングは日常茶飯事な事もあり、
同様の環境でSSHしても繋がっていたので、
『L4が問題になっている事は無いだろう』と、先入観から後回しにしたので時間がかかった。
今回はProxmoxのファイアウォールを全許可で有効化していたのが原因だが、
同様の事は他の仮想サーバやAWSの様なIaaSでも起こりうると思う。
非対称ルーティングはNW設計次第で起こりうるからこそ、
通信出来ない時は低レイヤーを切り分けつつ、セオリー通りL4は見るべきと再認識した。
« 続きを隠す
