固定IPv4でサーバ公開したい。

でもIP4 over IPv6とPPPoEの併用で、L3設計が徐々に崩壊していった。RTX830導入で、ようやく意図を設計に落として動くネットワークへ戻せた話。

はじめに

家庭用ルータで自宅サーバを運用していると、ある程度までは問題なく動きます。

しかし、構成が複雑になるにつれて、

PPPoEとIPoEの併用
VPNやポートフォワードの増加
内部ネットワークの分離

といった要件が積み重なり、徐々に「無理やり成立させている状態」になっていきました。

最終的には、設定の複雑化と挙動の不安定さが限界に達し、構成そのものを見直す必要に迫られました。

そこで導入したのがRTX830です。

本記事では、そこに至るまでの「段階的な構成変遷」と「なぜその判断に至ったのか」をまとめます。

初期構成：固定IP導入前のシンプルなサーバ運用

当初は非常にシンプルな構成で、HGW配下に単一のサーバを置くだけの運用でした。固定IPがないため、安定した外部公開には制約がありました。IPoE接続のため利用可能ポートに制限があり、ダイナミックDNSを利用してもサーバ公開は現実的でなく、この時点では採用しませんでした。

この時点では「サーバ公開したら面白いだろうな」と思いを馳せてドメインを取得はしていましたが、内部で

取得したドメインでの正引きを中心に、逆引きも意識したDNS構成
サーバにIPv6アドレスを割り振り、HGWでドメインごとにDNSサーバを振り分ける構成
データベース連携によるマルチドメイン対応の（内部限定の）SMTP・IMAP（TLSなし）

を動かして、将来的な外部公開を見据え、内部でサービスを一通り成立させることを優先していました（外部公開に必要な前提条件を内部で検証する意図です）。しかし、この時点ではまだ外部公開を前提とした運用とは大きく異なる状態でした。

固定IP導入と外部公開の開始

内部でメールサービスを稼働させるだけでは満足できず、せっかく構築したサーバなら外部に公開したいと考えるようになりました。最小構成としてHGWでのIPv4 over IPv6を止め、PPPoEによる固定1IP契約に切り替え、ポート開放によるサービス公開を開始しました。

まず、必要になるのがSplit-Horizon DNSになります。内部からはプライベートIPアドレスでサーバにアクセスし、外部からは固定IPでアクセスさせる必要があるため、参照元に応じて名前解決結果を切り替える構成としました。また、メールの到達性と信頼性を確保するため、DKIM・SPF・DMARCの設定も行いました。外部から到達可能になったことで、Let's Encryptによる正規のTLS証明書も取得可能になりました。

この時点では外部公開自体は問題なく成立しましたが、運用を続ける中で徐々に問題が顕在化していきます。

PPPoE接続での転送量問題

この構成では、すべてのIPv4通信がPPPoEプロバイダ経由になります。IPv6 ReadyなサイトへはIPoEで接続可能ですが、IPv4 OnlyのサイトはすべてPPPoE側に流れる構成でした。その結果、IPv4 Onlyのサイトから大量の動画をダウンロードしたことによって1か月間の速度規制を受けてしまいました。

サーバはIPv4でしかインバウンド通信をさばけません。また、メールはSPF等との整合性の関係で、逆引き可能なIPv4アドレスで送信する必要があります。この問題は一時的なトラフィック増加によるものではなく、IPv4通信がすべてPPPoEに集中する構成そのものに起因しており、サービス公開環境としては無視できない制約となりました。特に外部公開しているサービスとクライアント側のトラフィックが同一経路を共有するため、意図せずサービス品質にも影響を与える構成となっていました。

安価なルータ追加によるサーバ通信とクライアント通信の分離

PPPoE接続にすべてのIPv4通信が集中する構成に限界を感じ、サーバとクライアントの通信経路を分離することを検討しました。

具体的には、安価なルータを追加しサーバをこのルータ配下に配置、クライアントはIPv4 over IPv6を再有効化したHGW配下に配置し、IPv4通信をIPoE側に逃がすことで、クライアントのIPv4通信がサーバ側のPPPoEに流れないように構成を変更しました。

この構成変更により、PPPoE回線の負荷はある程度軽減され、体感的な速度低下は改善されました。

しかし、サーバとクライアントがIPv4的に別セグメントになり直接の通信が行えなくなるので、サーバにNICを1枚追加し、そこにクライアントセグメントのIPv4アドレスを割り当てることでこの問題を解決しました。しかし、サーバが2つのIPv4アドレス、それも2つ共にプライベートIPアドレスであるという歪な構成になってしまい、L3設計の問題をホスト側で補う構成となりました。

その結果、通信経路の把握やトラブルシュートが難しくなり、構成変更時の影響範囲も読みづらくなるなど、設計としての一貫性も崩れ始めていました。

IPv6経路の気づき：構成を見直すきっかけ

追加したルーターはIPv6パススルーの設定が行えるため、ルータ配下のNICのIPv6を有効化するとサーバからのアウトバウンド通信をIPv6側へ逃がせることに気づきました。

この構成では、いわゆるHappy Eyeballsの挙動（接続確立が速い方が選ばれる（結果的にIPv6が勝ちやすい））により、アウトバウンド通信はIPv6が優先されるようになり、結果としてPPPoE側の負荷を軽減することができました。

ただし、メールについては送信元IPの逆引き整合性が重要となるため、意図的にIPv4（PPPoE側）を優先するよう調整が必要でした。

つまり、「通信ごとに経路制御を考慮する必要がある」状態となっており、構成としては成立しているものの、本来ルータで統一的に制御すべき責務がサーバ側に分散している状態でした。

この時点で、個別の対処ではなく、ネットワーク全体のルーティング設計そのものを見直す必要性を強く意識するようになりました。

構成の歪みを解消する：PPPoE Unnumberedによる再設計

これまでの構成では、L3設計の問題をサーバ側で補う形となっており、通信ごとに経路を意識する必要がある状態でした。

この問題を根本的に解決するため、サーバに直接グローバルIPアドレスを割り当てる構成を検討しました。

そこで選択したのが、PPPoE Unnumbered契約です。PPPoE Unnumberedとは、ルータのWAN（回線側）にIPアドレスを割り当てず、ルータのLAN側アドレスブロック（8IPだと/29）がそのまま上流にルーティングされる方式です。

IPv4 over IPv6とPPPoEを分離するために購入した安価なルータは、PPPoE Unnumberedにも対応しておりましたので、プロバイダ契約後、ルータの設定もそれに合わせます。

また、これによりサーバにグローバルIPを直接割り当てることが可能となり、

主NIC：グローバルIPv4アドレス・IPv6 GUAアドレス
副NIC：プライベートIPv4アドレス

を割り当てます。

再設計のはずが、再び歪みが生まれる

ルータの機能がまともであれば、NIC2枚のサーバをゲートウェイに設定し、お互いのセグメントの相互通信が行えます（ルータのWANはプロバイダに向いているので、このルータをセグメント間のルータにはできません）。しかしこのルータは別セグメントへのデフォルトゲートウェイを設定できない、というバグにも近い挙動を示しました。

しかも、大きなサイズのパケットをDropするので、ルータ配下のNICのMTUを1400にするという場当たり的な解決を行う必要がありました。

正しさのためにPPPoE Unnumberedを契約したのに、ルータの制約で正しくない設定を強いられた形になります。この状態では、個別の問題に対して都度対処することはできても、構成全体としての正しさや再現性を維持することは困難でした。

もはや「動いているからよい」という段階ではなく、設計そのものを正しく実装できる基盤が必要な状態に達していました。

本来ルータが担うべきL3制御の責務がホスト側に流出している状態では、これ以上の構成改善には限界がありました。

設計を取り戻すためのルータ導入

ここまでの構成でも、通信自体は成立していました。

しかし実際には、

L3制御がホスト側に流出している
通信ごとに経路を意識する必要がある
機器の制約によって設計が歪められる

といった状態となっており、構成としての一貫性や再現性を維持することが困難になっていました。

本来ネットワークで担保されるべき制御がアプリケーションやホストに分散している状態では、これ以上の改善には限界があります。

そこで、ネットワーク全体を一貫して制御できるルータの導入が必要であると判断しました。

日本のNGN環境、特に今回のようなPPPoE Unnumbered構成を前提とした場合、安定した運用を実現するには対応実績のあるハードウェアルータが必要であると判断しました。一方で、Cisco等のエンタープライズ機器はコスト面で現実的ではありません。その中で、NGN環境への適合性と機能のバランスを満たす選択肢として、RTX830を採用しました。

また、IPv6の単一L2への複数プリフィックスにも対応しているので、ULAも採用することにしました。

VLAN対応HUBとRTX830によるネットワーク設計の完成

RTX830の導入により、L3の制御は完全にルータ側へ戻すことができました。

一方で、セグメント分離を物理配線だけで実現しようとすると、構成はすぐに複雑化してしまいます。ここで活きてきたのが、偶然、たまたまVLAN対応HUBをすで使用していたことです。

RTX830とVLAN対応HUBを組み合わせることで、

サーバセグメント
クライアントセグメント
公開用セグメント
管理用セグメント

といったネットワークを、物理配線を増やすことなく論理的に分離できるようになりました。

また、RTX830側でVLANインタフェースを終端することで、セグメント間のルーティングはすべてルータ側で統一的に制御されます。

これにより、

L2：VLANで分離
L3：RTX830で制御

という責務分担が明確になり、これまでホスト側に流出していた制御を完全にネットワーク側へ戻すことができました。

結果として、

通信経路は明示的に把握可能
経路制御は一元化
構成変更の影響範囲も予測可能

となり、ようやく「設計通りに動くネットワーク」を実現することができました。

サーバのNICについても、トランクポートに接続してVLANを設定することで、単一NICで複数セグメント対応が可能となりました。

ようやく、「ネットワークはネットワークとして設計するもの」という状態に戻すことができました。

ベアメタルサーバから仮想化へ

ネットワーク設計が整理されたことで、ようやくその上に載せる基盤にも手を入れられる状態になりました。

VLANのトランクポートへ仮想基盤を接続することにより、接続するセグメントに制約なく、仮想マシンを稼働させることが可能となります。

実は、セールで安く販売されていたミニPC（i7-1165G7 & I226-V NIC）を入手しております。大きめのSSDとメモリを入れた後、Proxmox Virtual Environmentを入れ、複数VMにてベアメタルサーバのリプレースを行う予定です。

正しいネットワークが正しい仮想化を可能にしました。インフラは積み上げるものではなく、設計するものだということを、今回ようやく実感しました。