DigiLoog

PC関係の事なら何でもいけるそんな処

Proxmox上の仮想ルータで非対称ルーティングが遮断された話

2022年01月10日(月) - 21:56 | カテゴリ: Network

Proxmox上に構築したVyOSと、物理ルータのEdgeRouterで非対称ルーティングを組んだ所、
pingは通るのにTCP通信(SSH)が通信出来ない不思議な現象が起きたのでその備忘録。

“ns-lab BB”のバックボーンは拠点間をVyOS系のルータでVPN接続しつつ、
プライベートASとBGPを使ってトラフィック交換している。
今回の舞台となるNWトポロジーは次の様になっており、
VyOSが1台・EdgeRouterが3台の合計4台でコアNWを形成しつつBGPピアを張っていた。

VPNは二面構成にする事でマルチホーム試験も出来る様にしており、
それぞれのNW間で迂回させられる様にAS内でiBGPピアも張っている。
また、二面構成にしているのでMEDを使ってトラフィックを分散させ、
上り・下りのトラフィックが偏らない様に経路制御をしていた。

BGPスピーカー本体でHSRPも喋らせつつサーバのデフォゲにVirtual IPを指定する事で、
サーバ直上トラフィックはActiveに寄せながら、BGPによって他ASへの通信を制御していた。

ちなみに、VyOS系なので実際はVRRPですが、
画像作ってから気づいて修正が大変なのでHSRPをVRRPに読み替えてください(´・ω・`)
以下説明でも画像と合わせる為、標記はHSRPに統一しています。

つまり、ルーティングの広報次第では非対称ルーティングになるのだが、
NW構成にProxmox上の仮想ルータを組み込んで非対称ルーティングにしたら通信出来なかった。

最初に結論を書くと、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は見るべきと再認識した。





  • 応援中

    はじめるセカイの理想論 -goodbye world index-