1台のPiでhostapdとOpenVPN：デフォルトルートは誰のもの？

スマートフォンはアクセスポイントに接続し、アドレスを受け取っても、トンネルが上がった途端に何にも到達できなくなります。その状態でもhostapdは通常健全で、OpenVPNも同様で、壊れているのはデフォルトルートで、ブリッジに最初から存在しなかったか、VPNサーバー自身への経路を残さずにトンネルが置き換えたかのどちらかです。この手順書はそのルートを本来の場所に戻し、結果をPiからではなくクライアントから証明します。すべての手順は元に戻せますし、ここではトンネルの中にどの通信を入れたいかが分かるまでトンネルの設定を変えません。

何かを編集する前にインターフェースを棚卸しする

よくある構成では、無線と有線ポートをbr0の中に置き、hostapdをブリッジに対して起動し、dnsmasqからリースを配り、OpenVPNクライアントがtun0を作り、三つの別々の要件が一つに見えます。アクセスポイントのクライアントにはゲートウェイとしてのPiが必要で、Piにはサーバーへ届くためのインターネットへの経路が必要で、ブリッジにはそれらのクライアントが使えるゲートウェイアドレスが必要です。

変更する前に現在の状態を読み取ってください、なぜならこの四つのコマンドがインターフェースの問題とルーティングの問題を切り分けるからです。

ip -br addr
ip route show
ip link show master br0
bridge link show

br0がアドレスを持っていてもデフォルトルートがなければ、クライアントはPiまでしか届きません。トンネルが落ちている間にデフォルトルートがtun0を指していれば、Piには動く経路がまったくなく、クライアントの症状はまったく同じに見えます。どちらもスマートフォンからは同一に見えるので、ルートテーブルを直接読む必要があります。

ブリッジに自分自身のデフォルトルートを与える

Raspberry Pi OSは、インターフェースファイルを書いた後にブリッジができた場合、ブリッジをデフォルトルートなしで残すことがよくあります。スタンザは/etc/dhcpcd.confに入れるべきで、Piではなく上流ルーターを指すべきです。

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

この例では192.168.50.1が既存のルーターで、192.168.50.2が同じサブネット内のPiのブリッジアドレスであり、数字をコピーするのではなく、自分の計画に置き換えてください。ブリッジのメンバーもルーターを要求してはいけません、そうしないとPiに競合するデフォルトが残り、その勝者は意図ではなくメトリックとタイミングで決まります。

systemctl restart dhcpcdの後、ip route show defaultはbr0を一度だけ示し、有線ポートからの重複がないはずです。テーブルではなく検索結果を確認してください、古いエントリが勝者の隣に残ることがあるからです、つまりip -4 route get 203.0.113.10がbr0を指す必要があります。このアドレスはTEST-NET-3のドキュメント用範囲なので、これを読んでいる間に実在のサーバーと衝突することはありません。

トンネルが自分自身のサーバーへの経路を奪わないようにする

redirect-gatewayを受け入れるOpenVPNクライアントはデフォルトルートを引き取り、トンネルへ向けます。すべてのアクセスポイントのクライアントがVPNを使うべきなら正しく、一部の宛先だけが使うべきなら誤りです。いずれにせよ、Pi自身のサーバーへの接続は、まだ構築中のトンネルの中を通ってはいけません。OpenVPNはデフォルトをリダイレクトするとき、元のゲートウェイ経由でリモートへのホストルートを追加し、これがトランスポートを生かし続ける挙動そのもので、そのルートが欠けていると、トンネルは確立すると同時に崩壊します。

接続前と接続後でそのトランスポート経路を素早く比べる価値は、その十秒にあります。ip -4 route get 203.0.113.10はどちらの状態でもアンダーレイのデバイスを示し、変わるのはメトリックだけのはずです。トンネルが上がった後にtun0を示すなら、ホストルートは一度も入っておらず、次の再接続は失敗します。

選択したプレフィックスだけをトンネルに通す場合は、route-nopullを使い、必要なルートを手で追加するか、サーバーからより狭いセットを配ります。その設計ではブリッジがデフォルトルートを保ち、次はDNSの判断です、つまりdnsmasqを家庭内リゾルバーへ転送するのは、実際にそこに住む名前に対してだけ意味があります。

転送とNATの方針を決める

フルトンネルには、Piで転送を有効にすることと、アクセスポイントのサブネットをルーティングしてくれる相手側ゲートウェイが必要です。何よりも先に転送を確認してください、ゼロならルートの変更はすべて無意味になります。

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NATルールは、サーバーがアクセスポイントのプレフィックスを受け入れないときに効く近道ですが、代わりに相手側のログではすべてのクライアントがPiのトンネルアドレスとして見えます。NATなしでプレフィックスをルーティングすればアドレスは見えたままで、家庭側に192.168.50.0/24の戻りルートが必要です。

選択はファイアウォールのルールの横に書き留めてください、設計で見えないNATルールは半年後に説明不能になります。IPv6も同じ判断に入れます、壊れたIPv6経路の隣にある動くIPv4経路は、ブラウザーでは依然として半分壊れて読めます。

クライアントから検証し、それからきれいにロールバックする

アクセスポイント上のスマートフォンやノートPCから、この順で試します、dnsmasqからのリース、ブリッジアドレスへのping、次にトンネルの向こう側の宛先です。各手順が一つの層を切り分けるので、役に立たない単一の失敗になりません。

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

次に、Pi自身の出口がまだあることを確認します、ip route get 203.0.113.10はアンダーレイのデバイスを示し、サーバーがICMPを許すならping -c 3 -I br0 203.0.113.10が応答するはずです。クライアントの最初の二手順が通り、三番目が失敗するなら、障害は転送かNATにあります。二番目の手順が失敗するなら、ブリッジかDHCPがまだ不完全です。

ロールバックは一つのファイル編集と二つのコマンドです、スタンザを削除し、dhcpcdを再起動し、デフォルトルートをip route replace default via 192.168.50.1 dev br0で明示的に置き換えます。メンテナンスウィンドウが閉じる前に実行してください、閉じた後では、デフォルトルートを失ったPiは修復に使うはずのネットワークから到達できません。