ISPルーターの隣にサイトVPNを追加し、通話を止めない方法
ISPルーターのインターネットと音声の役割を保ったまま、2台目のゲートウェイにプライベート経路を持たせます。経路を変える前に、次の5つの確認を行ってください。
小規模サイトの多くは、インターネット、DHCP、音声回線を一台の機器でまかなっています。その機器がサイトのトンネルを担うことはありません。プライベート経路用に二台目のゲートウェイを足す方法は、ケーブルに触る前にどの経路を誰が持つかを決めておけば機能します。本当のリスクはトンネルではなく、電話機を登録状態に保つ機器を黙って入れ替えることです。五つの確認を順に行い、失敗したところで止めてください。
すでに機能している役割を書き出す
デフォルトゲートウェイ、DHCPサーバー、リゾルバー、そしてプロバイダーの音声登録を持つ機器を記録します。この例ではISPルーターが10.50.0.1、新しいゲートウェイが10.50.0.2、遠隔サイトが10.60.0.0/24です。この計画で最初の三つの役割は変わりません。そこが要点です。次に、二台目が本当にトンネルを終端できるかを確認します。プロトコル、想定スループット、ファームウェアやパッケージの更新が届くかを見ます。VPNのロゴだけあって更新経路がない機器は、追加ではなく負担です。
音声サービスを誰が持つか言えないなら、止めてください。登録を持つルーターを切り戻し計画なしで変えるのは、VPNプロジェクトを電話障害に変える近道です。
新しいゲートウェイにアドレスを一つ、仕事を一つ
LANアドレスはDHCPプールの外で予約し、再起動後に動かないようにします。インターネット経路にするつもりがなければ、独自のデフォルトルートは与えません。役割はトンネルを保持し、遠隔プレフィックスに応答することです。遠隔サイトへ到達する必要があるLANホストでは、現在どの経路を通り、変更後にどれを使いたいのかを証拠にします。同じ二つのコマンドを前後で実行するのが最も安い証拠です。
ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55
参照がISPルーターを返し、tracerouteがインターネットの縁で止まるなら、そのホストにはまだ遠隔経路がなく、これは想定どおりです。想定外の結果が返るなら、まずそれを解決してください。以降の手順はすべてこの基準を前提にします。
遠隔プレフィックスの経路を誰が持つかを選ぶ
選択肢AはISPルーターです。10.60.0.0/24への静的ルートをゲートウェイ向けに持ち、各ホストはこれまでどおりデフォルトゲートウェイに従います。選択肢Bはホスト単位です。遠隔サイトが必要な機械だけが10.50.0.2経由の明示的なルートを受け取り、それ以外は手を付けません。Aはホストが多いとすっきりしますが、プロバイダーのルーターが静的ルートを受け入れる必要があり、受け入れない機種もあります。Bはプロバイダーの協力を要しませんが、ホスト設定の保守が残るため、承認済みの少数の機械に向きます。
どちらでも戻りの経路が必要です。遠隔からの応答がゲートウェイに届き、ゲートウェイがLANホストへ直接転送すると、ISPルーターが往路で保っていたファイアウォール状態を迂回します。ゲートウェイがLANのデフォルトルーターでない場合、その非対称は設計上の判断であり、無視してよい不具合ではありません。
ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77
設定はホストの構成管理側で永続化し、ログインスクリプトには頼りません。誰かがログインした後だけ存在するルートは、無関係な理由でマシンが再起動した最初の機会に失敗します。
到達可能な受信エンドポイントを用意する
ゲートウェイには遠隔サイトが到達できるアドレスが必要です。ISPルーターの背後ではポート転送かDMZエントリが必要で、どちらもプロバイダーが実際に通信を届けるかにかかっています。ローカルの転送ではプロバイダー側のキャリアグレードNATを越えられません。プロバイダーが到達点を出さないなら向きを逆にし、両サイトから自分が管理するハブへ接続を開始させます。有効な設計ですが、転送、信頼、可用性という三つ目の依存が増え、動的DNSでは代われません。
転送はゲートウェイでのパケットキャプチャーで確認し、ポートスキャンのウェブサイトでは確認しません。スキャナーは待ち受けが結び付くまでポートを閉じたまま報告し、通信を一度も届けない転送は外から見ると閉じたポートと同じです。
プライベートサービスと音声回線を同時に受け入れる
LANホストから、プライベートDNSとアプリ自身の資格情報を使って想定の動作を試します。ルーティングされたトンネルは遠隔の閲覧をローカルEthernetセグメントのようにはしないため、検出と名前解決には独自の手当てが要ります。
curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55
そのうえで、同じホストから通常のインターネット接続がまだ動くこと、電話機がまだ登録されていることを確認します。この二つがデフォルトルートの誤変更を捕まえます。触るつもりのなかったものを壊す最も一般的な経路だからです。最後に復旧メモを書き残します。どの機器がどの役割を持ち、予約アドレスは何で、遠隔プレフィックスのルートを一手順でどう外すか。きれいに撤回できるプライベート経路は、今日だけ動く経路より価値があります。