家のテレビ用プロジェクタには、いくつかの機器から出力できるようにHDMI切替器で分岐させています。
HDDレコーダーからの映像をプロジェクタに出すとき、ときどき「No Signal」になるのが微妙に不便だったんですが、その原因がどうもこのHDMI切替器にありそうな気がしていました。切替器を通すことで信号の減衰が起こっているんじゃないかと。
それだったら、電源から給電できるタイプの切替器にしたらいいのかも？
と思って、だめもとでこちらに替えてみたところ、「No Signal」がまったく出なくなりました！
実家に置いてきたProxmox環境のミニPCですが、
何種類ものVPNでOpenWrt区画につなげられるようにしてあるので、遠隔メンテナンスは一応できます。
でも今後こまりそうなのが、OpenWrt区画が遠隔から一時的に使えなくなるようなメンテナンスをするとき。
たとえばファームウェアのメジャーバージョンアップがあった場合、最初に設定がいったん初期化されてしまうので、遠隔からは何も操作ができなくなってしまいます。
そうでなくても、うっかりWAN側の接続が切れるような操作をしてしまうこともあるし、今のOpenWrtとは別のメンテナンス経路を確立しといた方がよさそうやなあ。
(1) 今あるOpenWrtに頼らず、遠隔から実家のProxmoxに接続できるようにする。
(2) 実家の無線ルータが買い替えとかでサブネットが変わってしまっても、影響を受けないようにする。
(3) このバックアップ経路自体、短時間で構築できるような手法を選ぶ。
実家ミニPC–実家無線ルータ–インターネット
実家ミニPCはこんな感じで実家無線ルータの配下にいて、DDNSとポートフォワードでOpenConnectやSoftEtherの接続を受けるようにしています。
要件(1)(3)だけなら、Proxmoxの管理ポートをただインターネットにさらすという手もあるんですが、セキュリティ的にこわいのと、要件(2)で実家の無線ルータが交換されたときにポートフォワード設定を入れ直さないといけなくなるので不採用。トラブル時の応急対応とかではやるかもしれないけれど。
ということで、こちらを参考にProxmoxのLXCでTailscale専用コンテナを作って対応することにしました。
ハードウェアリソース的には、OpenWrtをもう1つ立てる方が小さくすむんですが、コンテナの方が手間が少なくてよかったです。構築だけなら10分ぐらい？
参考にしたブログでは、
テンプレート：AlmaLinux 9
ディスク：32GB
CPU：2コア
メモリ：2048MB
という構成で構築されていましたが、今回は
テンプレート：Debian 12
ディスク：1GB
CPU：1コア
メモリ：128MB
こんなふうにしました。ディスク使用率は76%で、メモリ使用率はMAXでも50%を少し超えるぐらいです。これがミニマム構成かな。
そしてネットワークインタフェースは、ミニPCのLAN側・WAN側両方に足を出していて、LAN側は固定IPで、WAN側はDHCPで割り当てるようにしてあります。
(ミニPCのWAN側というのは、セグメント的には実家無線ルータのLAN側です。)
WAN側に足を出したのは、OpenWrtに頼らずインターネットに接続するため。DHCPにしてあるのは要件(2)で実家のサブネットが変わっても追従できるように。LAN側に足を出したのは、Proxmoxに接続する宛先IPアドレスを固定するためです。
Tailscaleで外部から接続すると、–advertise-routesに含まれないプライベートIPアドレス空間には接続端末から直接通信ができなくなってしまいます。たとえExit Nodeになっていたとしても。
ふつうなら今あるサブネットをぽちぽち登録していけばいいんですが、実家の無線ルータの交換やOpenWrtの設定変更で未知のサブネットができても設定変更せずに通信できるようにしたいです。
ということで、思い切って
–advertise-routes=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
こういう設定でいくことにしました。プライベートIPアドレス空間全領域。
端末のTailscaleクライアントで接続して使うだけなので問題ないけど、このtailnetにほかのルータから–accept-routesするのは危険かも。
このバックアップ経路があれば、遠隔からOpenWrtを1から再セットアップすることもできそうです。
もしこのTailscaleコンテナ自体を、OS部分(Debian 12)含めてアップデートをしたくなるようなことがあっても、最新のテンプレートから作り直せばいいだけなので楽です。
あと、実家の無線ルータが交換された場合も、管理者パスワードさえ教えてもらえれば、ポートフォワード設定はこちらからできるので問題なさげ。
金盾のアクセス制限を回避するのにVPNが使われますが、
中国から中国のサイト(高德地图とか)にアクセスするときは、VPNで日本経由のアクセスにするとあからさまに応答が遅くなるので、接続先サイトのドメインによってVPNを通すか通さないかを変えたいです。
ということで、なんでもかんでもVPNを通すとこまることがあります。
そこでPBRを使って、通信の振り分けをすることにしました。
旅先用ルータのOpenWrtにpbr・luci-app-pbr・dnsmasq-fullをインストール。そして
LuCI > Services > Policy Routing > Basic Configuration
Use resolver set support for domains: Dnsmasq nft set
とセットします。
ふつうのルーティング設定は、宛先IPアドレスを使って経路の振り分けをするものですが、PBRを使うと宛先ドメインでの振り分けができるようになります。
それはルータが「名前解決する都度そのIPアドレスをルーティングテーブルに載せる」というしくみで実現しているので、名前解決はルータ自身でやらないと機能しません。つまり、端末側でDNS設定を8.8.8.8などにしていた場合には振り分けが発動しないんです。
なので端末のChromebook側では、「サイトのルックアップに安全な接続を使用する」をOFFにするだけでなく、DNSをDHCPで自動設定されるままにするなどする必要があります。
しばらくこれに気づかずはまりました。
PBRの経路Interfaceの選択肢には、デフォルト設定ではwanなど限られたものしか表示されないので、ここにVPN回線を追加しておきます。
LuCI > Services > Policy Routing > Advanced Configuration > Supported Interfaces
ここにVPNのデバイス名を追記します。ちなみに「デバイス名」というのは、
LuCI > Network > Interfaces > Devices
ここに一覧表示されるものです。
LuCI > Network > Interfaces > Interfaces
の方ではないので注意。
これもしばらく気づかずはまりました。
ただ単純に、Googleなどの金盾ブロック対象ドメイン宛の通信だけをVPNに通せばいいかというと、そう簡単にはいきません。
金盾は、DNS応答の改ざんでブロックを実現しているケースもあるので、こちらも対応しないと、改ざんされた接続先にVPNを通して接続しようしてしまって回避できません。
かといって、全部のDNS通信をVPNに通す設定にしてしまうと、最初にVPNトンネルを張るためのDNS問い合わせができなくなったりしてこまります。
端末からのDNS問い合わせは、ルータ自身を指さないとPBRが機能しないのでここはいじれない。なのでルータが名前解決する経路だけを制御したい。
そこでまず、特定ドメインの問い合わせだけふだんと別のDNSを指すようにします。
LuCI > Network > DHCP and DNS > Forwards > Additional servers file
/etc/dnsmasq.servers
と入力。そして旅先用ルータ上の/etc/dnsmasq.serversを以下のように編集します。
server=/google.com/1.1.1.2
server=/google.co.jp/1.1.1.2
(などなど、対象ドメインを列挙。このようにルートドメインだけ書いておけばサブドメインにも効きます。)
ちなみに1.1.1.2は1.1.1.1のマルウェアブロック版です。ふだんとちがう設定であれば何でもいいです。
そしてPBRで1.1.1.2宛の通信をVPN経由となるように経路制御します。
LuCI > Services > Policy Routing > Policies
に
Remote addresses / domains: 1.1.1.2Chain: outputInterface: (通したいVPNのインタフェース)
というようなルールを追加します。「Chain: output」はフォワードなどでないルータ自身の送信パケットの制御を指します。
今回旅先用ルータ-実家ルータ間に複数経路がある構成ですが、旅先用ルータ側でこのつなぎのVPNセグメントにIPマスカレードをかけておきます。
LuCI > Network > Firewall > Zones
で、VPNセグメントの属するゾーンすべてで
Masquerading
にチェック。
なにかとトラブルの元になる、行きと帰りで別ルートを通ってしまう非対称ルーティングを防ぐ目的です。OpenConnectでは旅先用ルータ側のIPアドレスがランダムに決まってしまうので、そもそも実家ルータ側に戻りのルーティング設定が固定で入れられないという事情もあります。
実際に使ってみての改善点の話です。
実家では、快適な中国旅環境のために、2台のミニPCをがんばってセットアップしていました。
今のところの構成はざっくりこんな感じで。
旅先用端末–旅先用ミニPC–(複数プロトコルのVPN回線)–実家のミニPC–インターネット
この「複数プロトコル」というのは、今年金盾を越えた実績のある
ZeroTier
SoftEther
OpenConnect
この3つで。ちなみにブログでは書いてなかったけど、
前回の中国ではMillenVPNを契約してOpenConnectプロトコルも最初の5日間だけおためししていました。
これでミニPC間にVPNトンネルを常時張っておいて、3つのうちどのトンネルを通すかは手動で切り替えられるようにしてあります。そして、高德地图など中国のサービスにはVPNを通さず直接接続できるようにも。
★Proxmox上のOpenWrt
これはProxmoxの仕様みたいなのですが、
LuCI > Network > Interfaces > Devices
で表示されるデバイスそれぞれでAdvanced device optionsのEnable promiscuous modeをenabledにしないとパケットのフォワーディングがうまく機能しません。
これけっこうはまりました。
★VPN回線のリンクアグリゲーション
ZeroTierとSoftEtherはレイヤー2接続ができるので、リンクアグリゲーション(OpenWrt用語ではBonding Connection)でたばねたら手で切り替える必要なく使えて便利そうやなあと思ってやってみたんですが、これがうまくいきませんでした。
たばねることはなんとかできたんですが、片方をわざと切ってみたときに、通信がかなり長期間切れてしまって使い物になりませんでした。
それなら手で切り替えた方が早いということに。
★SoftEther
SoftEtherは通信の安定する構成を見つけるのに時間がかかりました。
まずサーバ側。OpenWrtのsoftethervpn5-serverは安定しませんでした。クライアントからつないでも5秒ぐらいでセッションが切られてしまいます。
なので、OpenWrtのsoftethervpn-server(4.38-9760-r2)を利用。
クライアント側は、OpenWrtのsoftethervpn5-clientもsoftethervpn-clientも安定しませんでした。そしてブリッジ(softethervpn5-bridgeとsoftethervpn-bridge)も安定しません。
結局、間にWindowsのゲストOSをはさんでWindows版のSoftEther VPN Client (Ver 4.43, Build 9799, beta)を利用するのが一番安定しています。Windowsをルータに仕立てるのには、
引き続きMyPublicWiFiのMultifunctional Hotspotモードを利用します。
★OpenConnect
OpenWrtのOpenConnectサーバ(ocserv)は、少し設定にくせがあります。
ZeroTierやSoftEtherのようにレイヤー2接続するような設定がなく、このソフト自体でDHCPサーバまで担当してしまいます。そして同時に接続する回線の数だけOpenWrt上でデバイスの数が増えて、インタフェース設定などもその数やらないといけません。
スマホのクライアントとしてCisco Secure Client-AnyConnectを使うと、パスワードが保存されないので接続のたびにパスワード入力が必要になってめんどうなので、
F-DroidのOpenConnectアプリを使うことにしました。
このとき注意が必要なのが、OpenWrtのOpenConnectサーバ側の設定。
DNS serversの設定にOpenConnectサーバ自身のIPアドレスを入れていても、なぜかスマホからだとこのDNSが応答しません。別ルータからOpenConnectでつないでいるときには応答するのに。
あと謎なのが、OPPO Reno7 AだとちゃんとデフォルトゲートウェイとしてVPN回線が使われるのに、Rakutan Hand 5Gだと使われないということ。これは未解決のまま。
そしてよくわからないのが、Cisco Secure Client-AnyConnectアプリでつないだときの挙動。最初は問題なくつながったのに、一度OpenConnectアプリでつないでしまうと、その後Cisco Secure Client-AnyConnectアプリでつなごうとしたときには
Ciscoセキュアクライアント
セキュアゲートウェイから受信したアプリ単位のVPN構成が無効です。ネットワーク管理者までお問い合わせください。
というメッセージが出てつながらなくなってしまいました。
これはもう使わないのでいいんやけど。
★Windowsライセンス
ミニPCの1台目は、Microsoftアカウント経由で物理PCのライセンスを仮想OSに移すことができたんですが、2台目はなぜか同じ方法をやっても失敗。「あとでもう一度やってください」的なエラーだったんですが、OSの再インストールをしてもうまくいきませんでした。
結局2台目にはWindowsを入れないことに。
★PBR
接続先ドメインごとにVPNトンネルを経由させるかどうかを制御するのにPBRを使ったのですが、こちらややこしいので別の日の日記に。
ややこしいPBRの話を書きました。
ひさびさに千葉に戻ってきました。夜行バス疲れました(>_<)
ガスもれ検査の立ち会いをして、更新されたクレジットカードも受け取りました。
今年はもう物理クレジットカード類の更新がないので、あと千葉の在宅しばりはマイナンバーカード更新ぐらいかな。
次の四川行きはGWの高値シーズンが落ち着いたあたりで出かけようと思います。