OpenWrtでLAN全体をOpenVPNクライアント化する：動く順序

ルーターのLAN全体をひとつのトンネルの背後に置くには、四つの独立した作業が要る。トンネルデバイスには所有者、ファイアウォールゾーン、上流方向への変換先、そして一部のクライアントをVPNの外に残すなら送信元アドレスによるルーティングが必要だ。接続はするのに何も通らないトンネルは、ふつうこの四つのどれかが欠けている。依存関係の順に作業すれば、最後に起きた失敗は直前に変えた手順のものになる。以下の各手順は目で確認できる結果で終わるので、次の手順が当て推量にならない。

何がトンネルを共有するかを決める

Wi-FiとDHCPを配るルーターは、自分でクライアントを動かせる。接続されたすべての機器が個別設定なしでトンネルの背後に入り、小規模な拠点の多くはこの構成を望む。トンネルが切れたときの影響範囲もこれが最も広く、すべての機器が一斉に経路を失う。LAN側には外へ出る生きた経路が何も残らない。

最初のルーターの背後に、独自のサブネットでクライアントを動かす二台目のルーターを置けば、トンネルはその機器だけに限定される。撤去も説明も容易で、引き継ぐ人にも伝えやすい。代償は、経路もポート転送もなしでは両側の到達性が得られないことだ。

どちらにせよ、LANのサブネットは重ならないようにする。同じ範囲だと片側が直結に見え、そして その結果生まれるブラックホールはVPNの不具合のように見える 何時間も。

トンネルに所有者を与える

トンネルは、名前とデバイスを持ち、独自のプロトコルを持たないネットワークインターフェースとして宣言する。するとネットワーク系がデバイスを作成・管理し、以降はすべてデバイスではなく名前でインターフェースを参照する。これがゾーンから見つけられる理由だ。

同じデバイスを二か所で作らないこと。宣言したインターフェースの隣に手作りのトンネルがあると、存在するがゾーンに入らないデバイスか、再読み込みで消えるデバイスができる。どちらもクライアントの失敗に見え、どちらも本当の原因を名指すエラーを出さない。宣言方式を選び、手作業のほうを削除する。

ネットワーク、ファイアウォール、VPNの設定で名前を同一に保つ。ゾーンはネットワークを名前で列挙するので、打ち間違いがあるとインターフェース自体は健全に見えたままトンネルがどのゾーンにも入らない。ポリシーのない健全なインターフェースは、最も見つけにくい状態だ。

ゾーンに入れ、それから転送する

ファイアウォールゾーンは、入力・出力・転送・マスカレードというポリシーの住む場所だ。どのゾーンにも入らないトンネルは選んでいない既定値に支配され、ルーターのクライアントが必要とする形にはまずならない。以下のスタンザはインターフェースを宣言し、ゾーンに置き、LANの通信をそのゾーンへ通す。

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

21.02より古いリリースでは同じインターフェース行は option ifname と書くので、貼り付ける前に導入済みファームウェアがどちらの形を解釈するか確認する。転送のスタンザは、LANの通信がそもそもトンネルを使えるようにする許可だ。これがないとデバイスは起動し、クライアントは接続し、そしてどのLANホストもトンネルに届かない。ルーターのクライアントで最も多い「つながっているのにインターネットに出られない」報告はこれだ。

VPNゾーンのマスカレードは、パケットが出る前にすべてのLANアドレスをルーターのトンネルアドレスへ畳み込む。これで遠端のサブネットへの戻り経路が不要になる。

遠端がすでにあなたのLANを経路として知っているなら、マスカレードを切れば送信元アドレスが見えたままになり、クライアントごとのログが意味を持つ。二つの選択は後で別のサポート質問を生むので、どちらかを選び、どちらにしたかを書き残す。既定のLANからWANへの転送を外すのは、それ自体の結果を伴う別の判断だ。外せばルーター自身のインターネット接続も一緒に失われる。

NATで本当の上流を名指す

変換ルールを手書きするファームウェアでは、出力インターフェースが壊れる欄だ。ルールが vlan2 を名指していても、セッションが ppp0 で終わるなら何もしない。インターフェースをまったく指定しないルールは、非公開のままであるべき通信まで変換しうる。どちらの誤りも自ら名乗り出ないのは、トンネルが動き続けるからだ。

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

そのルールの ppp0 を ip route か稼働中のインターフェース一覧にあるものに置き換え、LANホストがページを開く間にカウンタを見る。単一プロバイダーのルーターなら、上流に対するマスカレード規則ひとつでふつう足りる。トンネルインターフェース用の二本目の規則は、一本目の代わりにはならない。

次に、トンネルに入るものを決めるクライアントオプションを足す。redirect-gateway 指定はクライアントのインターネット通信をVPN経由で送り、これがないとトンネルはサーバーが押し出す経路だけを運ぶ。DNSに触る前に、結果の経路表を確認する。

二つ目のテーブルでWi-Fiを分ける

経路表ひとつに既定経路は二本入らない。だからトンネルを迂回すべき二つ目のSSIDには、独自のサブネットと独自のテーブルが要る。トンネル側のSSIDに独自の範囲を割り当て、テーブルを選ぶルールでその範囲だけをトンネルへ流す。

OpenWrtのポリシールーティングのパッケージは、まさにその組み合わせを表現する。手作業でも同じことができ、送信元ルールと、既定がトンネルデバイスを指すテーブルを使う。

両方のネットワークから分割を確認する。トンネル側SSIDのクライアントはVPNの出口アドレスを、通常のSSIDのクライアントはプロバイダーのアドレスを示すはずだ。両者が同じに見えるなら、ルールが誤った送信元に一致しているか、テーブルがまったく参照されていない。インターフェース名に依存するルールはデバイスの番号が変わると壊れるので、再接続の後にも試す。

時計とデバイスフラグを疑う

「 persist-tun 」フラグは再起動をまたいでトンネルデバイスを残す。サーバーには向くが、状態を一から作り直すべきクライアントを混乱させる。失敗した交渉を生き延びたデバイスが、どの手順が実際に壊れたのかを隠すから、ルーターのクライアントを切り分ける間は外す。クライアントが安定して接続してから戻し、それより前には戻さない。

時計はもうひとつの静かな失敗だ。電池式の時計を持たないルーターはエポックから始まるので、NTPが追いつくまで証明書の検査が失敗する。起動の一分後に接続するクライアントはたいてい時刻同期を待っているので、証明書に触る前にログの時刻を実際の時刻と比べる。