Raspberry Pi の VPN サーバーを Ethernet へ移行する方法

Pi を Wi-Fi からケーブルに切り替えるのは 五分の作業に見えますが、それは移行を 一つではなく 四つの独立した設定として扱う場合に限り成り立ちます。クライアントがダイヤルするエンドポイント名はそのままに、その下のアドレスだけを変えられます。実際に壊れるのは、古いアドレスに固定されたリスナー、まだ無線のリースを指すポート転送、引退させたと思っていたインターフェースから出ていく戻り経路です。この手順は各段階で復旧経路を開いたまま進めるので、切り替えに失敗しても再起動 一回で済みます。

何かを抜く前に 四つの所有者を記録する

切り替えが生き残るかを決めるのは 四つの設定です。Pi のアドレス、OpenVPN のバインドアドレス、ルーターの転送先、そして応答が通る経路です。ケーブルに触る前に 四つとも書き留めてください。無線のリースが消えると、古い値はマシンから読めなくなるからです。有線インターフェースは無線プロファイルを継承せず、Bookworm ではアドレスが NetworkManager に、Bullseye では dhcpcd.conf にあります。無線の MAC アドレスを固定した予約は eth0 について何も語りません。新しいアドレスは独自の証拠を必要とする新しい割り当てとして扱ってください。

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

リスナーが 二つ目の所有者です。サービスが特定のバインドアドレスで起動していれば、ソケットは古いインターフェースとともに死にます。すべてのアドレスにバインドしていればソケットは生き残り、ルーターの規則だけが残る修正対象になります。

転送先と戻り経路は、人が飛ばしがちな所有者です。まだ 10.42.7.24 を指す転送は、到着したハンドシェイクを Pi がもう持っていないアドレスへ送るため、クライアントはサーバー側のログ行が 一行も出ないままタイムアウトします。戻り経路が効くのは両方のリンクが一時的に有効なときです。Pi はルーティングテーブルが優先するインターフェースから応答し、それがパケットの到着したインターフェースとは限りません。下の経路検索はカーネルがどの送信元を選ぶかを示します。

新しいアドレスを信じる前に実際のソケットを読む

設定ファイルは意図を語り、ソケットは現実を語ります。覚えている設定を信じるのではなく、動いているサービスに何にバインドされているかを尋ねてください。OpenVPN 2.6 のマニュアル は --local を 一つのアドレスへのバインドと定義し、省略するとすべてのインターフェースにバインドすると述べています。

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

状態の列ではなくローカルアドレスの列を読んでください。10.42.7.24:1194 を示す行は、ソケットがこれから削除するアドレスに固定されていることを意味し、0.0.0.0:1194 や *:1194 はデーモンがインターフェースの変更に自分で追随することを意味します。アドレスが固定されている場合は、稼働中のソケットを手で書き換えるのではなく、プロファイルを編集してユニットを再起動し、その後サービスが証明書と鍵のファイルにまだ到達できることを確認してください。

到達可能なまま進められる順序で移行する

ここでは速度より順序が重要です。無線がまだ動いているうちに有線リンクを立ち上げ、新しいアドレスと戻り経路を確認し、その後で無線プロファイルを引退させます。この順序なら、代替が証明されるまで作業セッションを開いたままにできます。

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

最初のコマンドは eth0 が意図したアドレスを受け取ったかを答え、二つ目はカーネルが外部の宛先に使う送信元アドレスを出力するので、変更の前と後に実行してください。その送信元がまだ無線のアドレスなら、有線リンクはまだ優先経路ではなく、外部からのテストは OpenVPN と無関係な理由で失敗します。転送に触れる前にルーティングの優先度を直してください。

両方のリンクが有効なとき、Pi は無線のデフォルト経路を好むことがあります。先にインストールされたため、あるいは有線リンクのメトリックが高いためです。Bookworm でサポートされる設定は接続上の ipv4.route-metric で、Bullseye ではインターフェースごとの metric 行が dhcpcd.conf に相当します。切り戻し経路を 一コマンドの距離に保つため、無線リンクは無効化せず優先度を下げてください。

トンネルは LAN からではなく外部から証明する

ソファからつながる VPN 接続は見た目ほど多くを証明しません。LAN の内側から公開アドレスへの通信は、ルーターが一貫性なく実装する hairpin や反射の規則を通ります。そのため LAN でのテストが通っても、外部経路が壊れていることがあります。受け入れテストにはモバイルデータの携帯電話か、ネットワーク外の任意のホストを使ってください。LAN での試行は別個の任意の診断として残します。

次にパケットが到着する順にログを読みます。何も出ないならハンドシェイクが Pi に届いていないので、転送先かホストのファイアウォールが誤りです。始まって止まるハンドシェイクは鍵、証明書、MTU を示します。完了して落ちるセッションは通常、戻り経路か 二つ目のデフォルト経路を意味し、クライアントのログ行 Initialization Sequence Completed がトンネル自体の確立を教えてくれます。

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

クライアントが再試行している間にサーバーログに何も出ないなら、OpenVPN の設定を読むのをやめて転送先に戻ってください。キャプチャは到着の問いに数秒で答え、応答のない受信パケットは問題を経路に絞り込みます。

一ステップの切り戻しを保ち、無線プロファイルを引退させる

有線の構成が再起動を通過するまで、無線プロファイルはインストールしたままにします。nmcli con show が必要なプロファイル名を一覧し、削除したプロファイルは最悪のタイミングで記憶から作り直す羽目になります。インターフェース名、アドレス方式、メトリックを他の 四つの値の隣に記録してください。メモから入力できる切り戻しは、作り直す必要のあるものより価値があります。

無線への依存を引退させるのは削除ではなくプロパティの変更です。connection.autoconnect no を設定すると、認証情報とアドレス履歴を保ったまま、移動元のネットワークに Pi が再接続するのを止められます。

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

作業を完了と宣言する前に 四点を確認してください。転送先が有線のアドレスと一致すること、リスナーが再起動を生き延びたこと、外部のクライアントがハンドシェイクを完了すること、再起動後も Pi が有線のアドレスで応答することです。再起動は、実行中のカーネルにしか存在しなかった割り当てを捕まえる最も安い方法です。四つのどれかが失敗したら、sudo nmcli con up で無線プロファイルを戻し、記録した値と稼働中の値を比較してください。