IPv4接続なしでインターネットを使う
(jamesmcm.github.io)- IPv4接続が途絶した状況でも、IPv6とWireGuard、Hetzner VPSを使ってインターネット全体を利用できるようになった
- Carrier Grade NAT（大規模NAT） によりIPv4だけで障害が発生した一方、IPv6には影響がなかった
- WireGuardトンネルを設定し、VPS経由でIPv4トラフィックをトンネリングすることで、通常のWebサイト利用環境を復旧した
- ネットワーク名前空間とDockerの活用法、さらにMTU問題の解決方法も紹介されている
- Linux環境とオープンソースツールによって、複雑なネットワーク問題を自力で解決した経験を強調している
概要
数日前、筆者は停電の後に自宅ルーターでIPv4接続が切れる問題に見舞われた。幸いIPv6接続は正常だったため、一部のWebサイト（Google、Metaなど）にはアクセスできたが、大半のサイト（GitHubなど）には接続できない状態だった。そこでLinux、WireGuard、Hetzner VPSを活用し、IPv6だけでインターネット全体の利用環境を復旧した過程をまとめている。
障害の原因と背景
ネットワーク環境の異常を発見
- 停電後の復旧過程で、IPv6サーバーには正常に接続できる一方、IPv4サーバーには接続不可という現象を確認
- 診断コマンド（
ping -6、traceroute）の実行結果でも、IPバージョンによる差だけが確認された - 問い合わせの結果、通信事業者側のCG-NAT（Carrier Grade NAT）層でIPv4変換に問題が発生していたことが判明
- ISP側の復旧作業には数日かかる見込みだったため、自力での対処が必要になった
NATとCG-NATの説明
- NAT（Network Address Translation） : 複数の機器が1つのグローバルIPv4アドレスを共有できるようにする方式
- ルーターで内部IPをグローバルIPと固有ポートに変換してトラフィックを管理し、逆方向の転送時にはマッピング情報で内部宛先を復元する
- この構造により、暗黙のファイアウォールとしての役割やポートフォワーディングの必要性が生じる
- CG-NAT（Carrier Grade NAT） : ISPが各家庭用ルーターに対してさらにもう一段NATを適用する階層構造
- IPv4アドレス不足のため、ISP内部でNATを多重に適用している
- CG-NAT環境では、ポートフォワーディングなどのサービス提供がさらに制限される
- IPv4トラフィックだけで障害が起きた理由は、まさにこの層でのIPv4パケット処理の問題にある
IPv6の利点
- IPv6アドレス空間は圧倒的に広く、NATなしでも各機器に直接アドレスを割り当てられる
- 多くの家庭用ルーターには
/64サブネットが割り当てられ、数十億どころではない数のアドレスを利用できる
- 多くの家庭用ルーターには
- 別途NATは不要なため直接通信できるが、そのぶんファイアウォール設定はより重要になる
- CG-NATはIPv4にのみ適用されるため、この障害ではIPv6だけが正常に動作した
- ただし、まだ多くのサーバー（例: GitHub）はIPv6だけではアクセスできない
WireGuardトンネルでIPv4を復旧
実装概要
- Hetzner VPS（IPv4/IPv6の両スタックをサポート） とWireGuardを活用し、IPv6のみでインターネット接続された状態から、インターネット全体へアクセス可能な環境を構築
- VPS上でWireGuardサーバーを運用し、クライアント機器とのトンネルを構築
- トラフィックはIPv6経由でVPSへ迂回され、VPSを中継して全サイト（IPv4を含む）へアクセス可能になる
- Dual-Stack Liteに似た仕組み
サーバーおよびクライアント設定例
- WireGuardサーバー構成ではIPv4/IPv6トラフィックの両方を処理
- MASQUERADE（動的IP変換）、SNAT（固定IP変換）ルールの例を含む
- 直接割り当てられたグローバルIPv6を活用し、NATなしでもそのままWireGuardピア接続が可能
- PostUp/PostDown項目は複数回記述でき、各コマンドを順番に実行できる
- クライアント設定例
- 直接割り当てられたIPv6アドレス、またはNATされたULAとの組み合わせ例を説明
- AllowedIPsに
0.0.0.0/0, ::/0を設定することで全トラフィックをトンネリング可能 - Google DNS（IPv4、IPv6）およびMTU設定方法も提示
トンネルは正常に動作
- 両側のWireGuard設定完了後、IPv4/IPv6の両方が正常にトンネリングされた
- 妻のPCにも同じ方法を適用し、Linux WireGuardクライアントを簡単に導入
- ただし、社内VPNとの同時接続は一般に不可能なため、追加のネットワーク名前空間の利用が必要になる
ネットワーク名前空間とDocker
機能と活用法
- voponoなどのツールでアプリケーションごとのネットワーク名前空間を作成し、その名前空間でVPNまたはWireGuardインターフェースを直接指定できる
- 別途MASQUERADEルールの指定が必要で、内部トラフィックをWireGuardトンネルへ強制的に切り替える
- 外部から隔離されたDNS、
gai.conf（IPv4優先のDNS設定）などの設定のコツも含まれる
- 名前空間内部でVPN接続とアプリケーション実行を行う方式の実装例
- 同じ名前空間内で複数のサービスを動かすことで、ネットワーク競合を未然に防げる
Dockerコンテナとの組み合わせ
- Dockerデーモンは基本的にホストのネットワークソケットを使うため、通常の名前空間実行だけではアクセスできない
- mount namespace、
/sysのバインドマウントなど、Unix仮想化の手法によるworkaroundを提示 - dockerdを名前空間内部で実行し、別個のソケットとデータルートを指定することで、コンテナ内のインターネット接続を復旧
- 複雑なネットワークブリッジ環境では追加設定が必要になる可能性にも言及
- mount namespace、
WireGuard MTU（MTU: 最大伝送単位）問題
- WireGuard接続後、一部のWebサイトだけに接続できない（SSLなど）一方で、pingは正常に応答する現象が発生
- さまざまなサイズのpingテストにより、MTUが高すぎて大きなパケットが途中でドロップされていたことを特定
- MTUを1280に下げることで問題は即座に解決
- MTUとは、1回で送信できる最大パケットサイズを意味する
- トンネル化／カプセル化のオーバーヘッドを考慮して適切なMTUを設定する必要があり、そうでないと大きなパケット送信時に接続障害が発生する
- IPv6では規格上の最小MTUは1280である
結論と活用アドバイス
- WireGuard VPNサーバー構築、ネットワーク名前空間の管理、Dockerの特殊環境設定、MTUトラブルシューティングなど、Linuxとオープンソースツールを活用したネットワーク問題の自己診断と解決経験を強調
- Hetzner VPSのようなサービスは価格に対して安定性が高く、WireGuardのような合法的なネットワーキングサービスを運用しやすい
- オープンソースのルーターファームウェア（OpenWRT）とLinuxネットワーキング技法の価値を再評価
- 自分でネットワークを管理・修正できる柔軟性は、リモートワーク環境で大きな利点をもたらす
- 十分な理解と練習があれば、複雑なネットワーク障害も自力で解決できる
参考資料
- Tailscale – How NAT Traversal Works
- ArchWiki – WireGuard use case の例
- Unix StackExchange – 名前空間内でのDockerのトリック
- AskUbuntu – DNS優先順位の設定
（関連スクリプト、config、ヒント、参考リンクは原文参照）
1件のコメント
Hacker News のコメント
タイトルはやや誤解を招く感じで、実際には「IPv6トンネル経由でVPSに接続してIPv4インターネットへアクセスする」という話に近く、一般には4in6と呼ばれるものだという内容
いずれにせよ興味深いやり方
うちのISPでIPv4に障害が出ると全体がすぐ落ちるので、サポート上の問題も比較的単純に発生するが、IPv6に障害が出ると部分的におかしくなり、低速接続や断続的な不通など妙な形で現れるという経験
特にゲートウェイがIPv6があると勘違いすると、ユーザー視点では一部機能だけ動かないなど、さらに厄介な形の問題として見える
最近IPv4が少し使えなくなったとき、Githubが開けなくてそこで初めて気づいた
最近はたいていの一般向けWebサイトはIPv6で正常に動く
ただし、ルーターがIPv4 DNSしか提供しない人たちは、完全にインターネットが切断される問題があった
Microsoftがもう少し気を配ってくれればと思う
IPv4が戻ったか確認するために、ルーターに割り当てたmDNSホスト名を覚えておく必要があった点もある
正直、家でIPv4が切れたことがあったが、妻はまったく気づかなかった
Google、Facebook、Apple/iCloud、CloudFlare系サービスのほとんどはIPv6で問題なく動く状況
自分の経験も似ている
IPv6の問題は本当に原因の切り分けと再現が難しく、「自分のPCでは動くけど？」の繰り返しになる
ほとんどのISPがいまだにIPv6を遮断している状況で、中小企業もIPv6を試すだけ試してAAAAレコードのようなものを忘れてしまうことが多い
そのためユーザーは、友人宅やカフェなどの低価格ISP環境では何か動くのに、自宅では動かないという状況に陥る
変に聞こえるかもしれないが、特別に良い解決策があるようにも思えず、結局はIPv4が消えてくれることを願うしかないのが現実
Happy Eyeballsのような手法（IPv4/IPv6接続を同時に試して速い方を選ぶ）もあるが、実際にはアプリケーション側で問題が起きることの方が多く、それを解決する一般的な方法が不足している
自分の場合はネットワークではIPv6を有効にしつつ、ブラウザーではIPv6 DNSを切るという妥協策を使っているが、満足はしていない
IPv6を使ってみたいがISPが提供しない場合、Hurricane Electric(HE)がかなり昔から無料のトンネルサービスを提供している
関連情報としては tunnelbroker.net, ipv6.he.net, Fedora設定法, Brandon Rozekブログ, DD-WRT設定法, Mikrotikフォーラムの自動更新スクリプト, RockyLinuxガイド など、さまざまなセットアップ方法がある
一つ注意点があって、ストリーミングサービス利用時にはこのトンネルがブロックされることが多く、VPN迂回と見なされて地域制限コンテンツのために遮断されることがある
それでもRA（ルーター広告）機能のおかげで、どんなネットワーク機器でも/64単位でIPv6ネットワークをブロードキャストでき、ルーターがHEトンネルを直接サポートしていなくてもネットワーク内の複数機器がIPv6アドレスを利用できる（ただしルーターがセキュリティ上RAをフィルタしない場合）
自宅で何かを自前で公開したいとき、ポートフォワーディングなしでIPv6だけでできるので非常に便利
Hurricane Electricのサービスは良いが、いまではISPがIPv6を標準提供することが増え、一般ユーザーはトンネルサービスから離れつつある
そして一部のネットワークサービスがhe.netトンネルを乱用または悪用と見なしてブロックすることが増えたため、結局自分のネットワークではIPv6利用をほとんど止めることになった
参考までに、Hurricane Electricのトンネルは必ずISPからグローバルIPv4アドレスを受け取っていないと動作しない
もしキャリアグレードNATなどNAT環境にいるなら、この方法ではなく別のソリューションを探して自宅にIPv6を導入する必要がある
HEの無料6in4トンネルをOpenBSDで5年間使っている「顧客」としての経験
/etc/hostname.gif0などのネットワーク設定だけで安定して動いているAWS上でIPv4なしを意図して構成したVPSクラスターとの通信にも使っている
AWSがIPv4アドレス料金を積極的に課しているので、この方法はコスト削減に非常に役立つと思う
もし本当にv6 only環境でv4接続が必要なら、公開DNS64+NAT64 Gatewayを使えば簡単に解決できる
nat64.netの公開Provider一覧 を参照
普段はDNSサーバーを切り替えるだけでよい
DNS64はAAAAレコードのないサイトに対して、NAT64ボックスへ接続できるようAAAAレコードを合成して返す
するとNAT64がトラフィックを受け取り、プロトコル変換とNATを行う
実習例としてdigやcurlコマンドを使えば、そのままgithubのような場所へ接続できる
ヨーロッパでは nat64.net を直接使ってもかなり快適に動く
実際に良い経験しかなかった
Cloudflare WARPを使うと、はるかに速い速度を体感できる
WARP経由でIPv4アドレスへ直接アクセスすることも可能
ときどきIPv6-onlyユーザーがいること自体が不思議に思える
昔の逆の状況（IPv4-only環境でIPv6接続が必要）では、サーバーを完全に制御できるなら、非常に手早く使える解決策としてSOCKS5プロキシ（
ssh -Dオプション）の利用が最良だったブラウザーだけSOCKSプロキシに設定すればすぐ使える
システム全体に適用すると、かえってssh接続が切れることもあり得るので、その点は気になる
自分も似た状況
2週間ほどIPv4障害のチケットが開いたままだが、「まもなく技術者が対応する」という返答ばかり繰り返されている
IPv6は正常なので、全面障害とは見なしていないようだ
ドイツではこのような場合に消費者補償に関する法規があるが、今回のケースが該当するか確認する予定
ブログ記事で提案されている方法の問題は、データセンターIP帯が多くのサービスでブロックされたり、CAPTCHAのような回避を要求されたり、VPN業者のIPのように扱われたりすることで、避ける方法があまりない
自分の場合は家全体で解決する必要があったため、ルーターでWireguardによるルーティングとNATルールを設定したが、Ubiquiti EdgeRouterのようなオープンな機器だったので助かった
もしFritzBoxだったらこの作業はもっと難しかったと思う
ただし、ルーター性能が足りず接続数が多いと遅くなる欠点があるので、ハードウェアオフロードに対応したIPSecへ置き換えるべきか悩んでいる
FritzBoxもVPN接続のための非常に優れたGUI設定手順を提供している
FritzBox to FritzBoxが基本前提だが、互換性のあるVPNならOK
固定IPv4/IPv6ルート設定も提供している
最大の問題は、相手側がどのIPSec暗号設定を要求しているかを把握することだが、Wireguardの方が簡単な一方で、逆にハードウェアアクセラレーションの問題がある
必要ならFritzBox全体設定をバックアップして直接編集し、チェックサムだけ再計算して再投入するテクニックもある
AVMはユーザーに見せていない膨大な詳細設定を隠していて、それは意図的
誤ってルーターを壊さないよう、わざと少し難しくしてある面がある
ドイツの事情はよく知らないが、オランダでは固定回線とモバイル回線の両方を同じISPで使っているなら、有線網に障害が出たとき無料モバイルデータを要求できる
可能ならISPにそのオプションを問い合わせることを勧める
長い時間が経っても、すべての機器やホームラボをIPv6に切り替える明確な理由が見つからない
ポートフォワーディングとファイアウォール設定の方がまだ直感的で、IPv6へ移ると数週間単位でトラブルシュート、ファイアウォール、アドレス再設定などの複雑さが予想される
自分が何か見落としているのか気になる
現実的には、今の段階で見落としているものはほとんどない
今後GoogleやCloudflareのような大企業が増え続けるIPv4アドレスコストを負担しきれなくなれば、IPv6にインセンティブを与える可能性はある（たとえばIPv4接続は速度制限など）
AWSも以前は未使用のIPv4 Elastic IPだけ課金していたが、今では使用中でも無条件で課金している
今後ゲートウェイやルーターをアップグレードするときは、IPv6をそのまま有効にしておくのがよさそうで、今はIPv4/IPv6デュアルで使えば既存機器や既存サービスも問題なく動く
IPv6の自動アドレス割り当てについては歴史的に方式が混乱していたが、SLAACに落ち着く流れで、ISP側ではDHCPv6をかなり長く使い続ける見込み
実際のところ、そこまで難しくはない
特別に複雑なホームネットワークでなければ、夕方に少し時間をかけるだけでIPv6設定はできる
ComcastならルーターでIPv6オプションを有効にするとISPからprefixを受け取り、それだけで自動的にネットワークへ広告されるので、必要なポートだけファイアウォールで開ければ終わり
見落としている点はない
エンタープライズ環境では、IPv6導入の利点よりも欠点や複雑さの方が大きい
自分は約3500台の機器、7棟、2本の10Gbps、1本の4Gbps WAN、そして26個のグローバルIPv4アドレスを管理している
これまでIPv6を使わなければならない理由はまったくなかった
デュアルスタックで運用すると不要なネットワーク負荷と複雑性が発生する
むしろ最近、固定IPv6アドレスブロックを受け取るために2回申請したが、いずれも却下された
実質的なメリットはなく、そもそも割り当てを受けるのも難しい状況
ARIN IPv6初回申請ガイド を見ると、
→ IPv4割り当てを保有
→ IPv6マルチホームを即時予定
→ 1年以内に13のエンドサイト（オフィス等）
→ 1年以内に2000個のIPv6アドレス
→ 1年以内に200個の /64 サブネット
のどれか1つでも満たしていないと申請対象にならない
Apple App Storeのポリシーで、すべてのアプリがIPv6-onlyネットワークで動作しなければならないという要件は本当に高く評価している
開発者視点では最初は驚くかもしれないが、消費者視点ではこういう要件は非常にありがたい
ただしこのポリシーは、サーバー側にIPv6アドレス保有を必須にはしていない
それなら、アプリ経由でgithubがv6でも接続できるのか気になる
会社の業務で内部インフラへアクセスするため、IPv6 only VPNをいくつも運用している
最大の問題は、WindowsとmacOSクライアントが必ずv6 DNSサーバーを必要とする点
クライアントがv6対応ネットワークにいる場合もいない場合もあるため、VPN内部で直接DNSサーバーを動かしてそれをクライアントへ自動配布しているが
VPN接続が切れた後もWireguardアプリが元のDNSへ復元できず、さまざまな問題が起きる
正確な方法は覚えていないが、macOSはv6アドレスだけ割り当てても問題なく動いた
ホストにULAアドレスを割り当てればよく、やり方さえ分かれば簡単
VPNアプリが直接IPv6-onlyネットワークにULAを追加するスクリプトを活用できる
ただし、作成したULAアドレスを放置すると、ユーザーが別のv6ネットワークへ移動した際に問題になる可能性がある
同じ状況ならsshプロキシ（
ssh -D 8080 user@hostname）で簡単にSOCKSプロキシ環境を構築できるこの接続後、ブラウザーのプロキシアドレスを
localhost:8080に設定すればよい自分もまったく同じ助言をしようとしていた
一時的な問題回避として非常に簡単で、必要なら常用ツールとしても優秀
ただし
sshd_configでAllowTcpForwardingが有効である必要がある自分は公共Wi-Fiを使うときはいつもこの方法を使う
VPNサービスに料金を払う必要もなく、信頼も不要で、自分のinfomaniakサーバーへSOCKSプロキシとして流せばよい
個人的にはIPv4に不満が多く、特に自分のISPが強制的にIPv4しか提供しないのでなおさらもどかしい
IPv6導入がここまで遅いのは技術業界の大きな失敗だと思う
誰が責任を負うべきなのか考えてしまう
ルーター製造業者が粗末なファームウェアを作っているのか、ISPのIPv4推進的なリーダーシップの問題なのか、IPv4アドレス投機家のせいなのか、ネットワークエンジニアやサポート要員の教育不足なのかなど、原因についてもっと根本的な議論が必要だと思う
インターネットがTLS 1.0から比較的うまく移行できたように、IPv4も移行できるべきではないかと思う
レガシーコード向けのAIプロキシのようなものが、将来は解決策になるかもしれない
TLS 1.0からの移行がより容易だった理由は、end-to-end principleのおかげ
サーバーとクライアントだけが新しいプロトコルをサポートすればよく、中間機器（ルーター、スイッチなど）はネットワーク層（IP）だけ見ればよく、TLS新バージョンとは無関係だった
ネットワークレイヤープロトコル（IP）まで変更すると、中間のネットワーク機器すべてに影響する
参考までに、TLS 1.3導入時にもmiddleboxがend-to-end原則を破ってトラフィックを監視・改変し、互換性のためにTLS 1.3がTLS 1.2再接続のように偽装する小細工を使わざるを得なかったという馬鹿げた話もあった
その違いは、TLSはサーバー/クライアントだけが対応すればよく、中間ネットワーク機器はTCPパケットだけ見れば済むこと
IPv6はサーバーとクライアントの間にあるすべての中間機器が対応しなければならないので、「最小公倍数」に縛られる技術だ
TLSのアップグレードでは大きく変わる部分はなかった一方、IPv6は同時に変えた部分が多すぎた
今振り返ると、IPv6は単にアドレスを64ビットに増やすだけだったなら、むしろもっと普及しやすかったのではという残念さがある
現実的には、多くの人にとって置き換えの実利があまりに少ない、あるいはほとんどないため導入に消極的なだけ
巨大なIPv4陰謀論のようなものがあるわけではなく、単に手間とリスクに対して効果が小さい
ネットワーク業界のジョークに、「IPv6はエンジニアリング上の問題に無理やり当てはめた学術的解決策」というものがある
大規模にIPv4との互換性まで維持しつつ、現場導入、運用、保守まで考えるとIPv6はあまりに複雑
事実上アドレス不足以外に実質的な問題もないIPv4が消えることはない
そのため現場ではIPv6が実効的なソリューションになれていない