vyos1.5 GREトンネル+dhcp relay
memo
eth0から謎にdhcpパケットでる
dhcpリレーのインタフェースは client側：物理インタフェース(eth) dhcp側：トンネルインタフェース(tun) ではなく dhcp側：物理インタフェース(eth) にするとtunに飛んでいく
VyOS における DHCP リレー検証ドキュメント
1. 概要
VyOS を DHCP リレーとして利用する際、GRE トンネル経由の環境で DHCP Offer パケットがクライアントにリレーされない問題が発生しました。本ドキュメントでは、現状のネットワーク構成、問題の発生状況、検証内容、考察と今後の対応方針についてまとめています。
2. 問題の概要
- DHCP Discover は、VyOS のリレー機能により宛先ユニキャストに変換され、DHCP サーバに正常到達。
- DHCP Offer は、DHCP サーバからブロードキャストまたはユニキャストで VyOS に戻るが、クライアント側へ正しくリレーされない。
- クライアントからの Discover パケットは正しく DHCP サーバまで届くものの、Offer パケットが途中でリレーされないため、クライアントが IP アドレスを取得できない状態となっています。
3. ネットワーク構成とインタフェースの設定
- クライアント ⇔ VyOS (DHCP リレー) ⇔ GRE トンネル (tun インタフェース経由) ⇔ DHCP サーバ
- クライアント側は物理インタフェース（eth）を使用。
- DHCP サーバ側は GRE トンネルの終端として動作（DHCP サーバ側でトンネル終端処理）。
- VyOS のリレー設定において、DHCP サーバ側のインタフェースとして tun を指定すると正しく動作しないため、物理インタフェース（eth）で指定したところ一部改善が見られた。
- ブリッジインタフェースの利用も検討されましたが、現状では問題解決には至っていない状況です。
4. 検証内容と議論の経緯
- Discover パケット：VyOS が受信後、リレー設定によりユニキャストに変換し、DHCP サーバへ送信。
- Offer パケット：DHCP サーバから送信され、VyOS に到達するが、その後クライアントへリレーされない。
- DHCP サーバ側のリレーインタフェースとして tun インタフェースを指定した場合、Offer パケットのリレーに問題がある可能性が指摘され、最終的には物理インタフェース（eth）を指定する運用に変更。
- GRE トンネルを経由する場合、パケットがどのインタフェースに到達しているのか、またリレー処理時にどの経路でパケットが送信されるのかの詳細な解析が求められる。
- 一部、Discover パケットは GRE トンネルを経由せず物理インタフェースで送信されている可能性もあり、トンネルと物理インタフェースの混在が影響している可能性が考えられます。
5. 考察と今後の対応
- VyOS の DHCP リレー処理において、トンネルインタフェース（tun）の指定が正しくサポートされていない可能性があり、結果として DHCP Offer のリレーが失敗する状況が発生。
- 物理インタフェース（eth）での指定により一部改善するものの、Offer パケットのリレーが完全に正常化していないため、内部処理やパケットの到達インタフェースに起因する問題が考えられます。
- より詳細なパケットキャプチャやログ解析を実施し、DHCP Offer パケットが VyOS 内のどのインタフェースに到達し、どの経路を通っているかを確認する。
- VyOS のドキュメントやフォーラム、バグトラッカーなどで同様の現象が報告されているか調査し、公式の対応や回避策がないか確認する。
- 必要に応じて、トンネル経由の環境以外でのリレー動作や、他の設定（例えばブリッジインタフェースの利用）も含めた検証を進める。
6. 結論
現時点では、VyOS の DHCP リレーにおけるインタフェース指定（特に GRE トンネル環境下での tun と eth の違い）が DHCP Offer パケットのリレー失敗の原因と考えられます。完全な解決には、より詳細な解析と設定の再検討が必要ですが、本検証結果を踏まえた上で、現状は別のアプローチも検討する方向で進める方針とします。
一旦諦める
← Go home