リモート変更の前にルーター VPN のロールバックを計画する方法
リモート VPN を変更する前に、ルーターに戻る方法を計画します。復元ページをテストし、帯域外パスを証明し、トリガーを作成します。
あなたは独自のセッションを伝送するトンネルを編集しようとしているので、あなたを救う作業は、変更後のスクランブル中ではなく、変更前に行われます。セーフティ ネットは VPN ページにはありません、これは復元画面、コンソール、または編集中のデバイスを経由しない 二番目のパスです。私は、編集しようとしている同じルーター インターフェイス上で 三つすべてを計画し、すべてがまだ機能している間にそのパスを 一回使用します。これは、私が順番に従うウォークスルーです。
必要になる前に復元フローを実行してください
変更を元に戻すページを開きます。pfSense では、[診断] > [バックアップと復元] です、 OpenWrt では、[システム] > [バックアップ/フラッシュ ファームウェア] です、 OPNsense では、[システム] > [構成] > [バックアップ] にあり、ファイルなしで以前のリビジョンに戻すこともできます。まだ何も復元していません。変更中にそのページがパスから開かれるかどうか、後で再起動が必要かどうか、および別のファームウェア リリースによって書き込まれたアーカイブが拒否されるかどうかを確認します。Netgate は、docs.netgate.com で独自のエクスポートと復元のフローを文書化しています。
復元では構成全体が交換されるため、一つのルールを元に戻すことはできません。アーカイブには、ユーザー、証明書、VPN キー、ファイアウォール ルール、およびログインできるユーザーを決定する管理インターフェイス設定が含まれています。そのため、変更の直前にエクスポートし、日付と変更する単一の設定をファイルに名前を付けます。一か月前のファイルを復元すると、一か月前のトンネルと 一か月前のキーも復元されます。
プラットフォームが同じリリースのアーカイブのみをロードする場合は、ここで注意してください、ファームウェアのアップグレードと 一つのウィンドウでの VPN 編集により、ルーターが受け入れないファイルが保持されたままになります。
トンネルを抜けて入る方法を証明する
同じラップトップから同じパブリック アドレスへの 二番目の SSH セッションは 二番目のパスではありません、両方とも一緒に死ぬ。独立したパスは、シリアルまたは KVM コンソール、ハイパーバイザーまたはクラウド コンソール、トンネルの背後にないホストから到達可能な管理 VLAN、独自の管理ルールを持つ 二番目の WAN または LTE モデム、またはサイト上の人間のいずれかです。
ルーターが正常な間に、選択したパスをテストします。その上でログインし、VPN ページを開き、保存する前に停止します。ロックダウン ルールによってダッシュボードへのアクセスのみが許可されている場合でも、それを修正する時間はまだあり、修正はルールの順序で拒否ルールよりも上に配置する必要があります。
ほとんどのルーターは管理サービスをインターフェイスまたはアドレス ファミリにバインドするため、そのサービスがリッスンする場所に帯域外ルートが到着する必要があります。ウィンドウのバインドを広げることは機能しますが、それ自体が依存するパスを変更することになります。
ファイルをエクスポートしてトリガーを書き込む
エクスポートをルーターやトンネルを失う可能性のあるマシンから移動します。ルーターのファイルシステムに保存されているバックアップは、まさに計画している障害が発生すると消失しますが、接続が失われそうなラップトップ上にバックアップが保存されている場合は、ほとんど改善されません。
そのファイルを資格情報として扱います。 これには秘密キー、事前共有シークレット、証明書マテリアル、およびパスワード ハッシュが保持されているため、ルーターのログインと同じ注意を払って暗号化するか保管してください。
次に、一文を書きます、変更から N 分以内に [[PATH]] から新しい管理セッションを開けない場合は、[[FILE]] を復元して再起動します。この文はスコープを 一つの変数に強制的に絞り込みます。一緒にコミットされたルート、DNS、およびファイアウォールの編集はすぐに保存されますが、もう一度試行すると二分するのに時間がかかります。
プラットフォームにコミット タイマーがある場合は、コミット タイマーを使用する
いくつかのプラットフォームでは、確認を怠ると変更が取り消されます。RouterOS セーフ モードは、端末で Ctrl+X を押して入力すると、セッションが切断されたときにそのセッションで行われた変更を元に戻します。Junos は、確認された未確認のコミットをロールバックします。Cisco IOS ペアはリロード キャンセルでリロードされます。エンタープライズ ファイアウォールは通常、自動復帰タイマーを使用して保留中の変更をステージングします。OpenWrt とほとんどのコンシューマ ファームウェアには同等のものがないため、スケジュールされた復元、ファイルを元に戻してサービスを再起動する cron ジョブ、または以前の構成での再起動など、タイマーを外部に設定する必要があります。
同様の名前の機能が同じ範囲をカバーすると想定しないでください。ある製品の自動復帰はファイアウォール ルールのみをカバーする場合があります、別のものは、自分自身に到達できるようにするために変更したばかりの管理ルールを含む、構成全体をカバーする場合があります。タイマーに依存する前に、タイマーが何を戻すかを読んでください。
タイマーはエクスポートされたファイルの代わりにはなりません。ここで最も重要なケースでは失敗します、つまり、セッションは存続しますが、管理プレーンは存続せず、何もリバートをトリガーすることはありません。
開いている接続ではなく、新しい接続をテストします
確立されたセッションは、新しいハンドシェイクがブロックされるたびに変更が加えられても機能し続けることがよくありますこれは、その状態がすでに存在しており、接続の作成時にポリシーが評価されるためです。変更後、リモート側から新しい接続を作成します、つまり、新しい SSH セッション、クライアントからの新しい VPN ハンドシェイク、ルータ LAN アドレスへの通常のページ ロードです。
# run these from the remote machine, in a new shell
ssh -o ConnectTimeout=8 admin@"$ROUTER_WAN"
nc -vz "$ROUTER_WAN" 443
dig +short example.internal "@$ROUTER_LAN"次に、トンネル自体ではなく、トンネルのダウンストリーム (名前解決、内部サービスへの TCP 接続、実際に使用するアプリケーション) をテストします。確立されているものの使用可能な DNS を配布しないトンネルは、クライアント ステータスでは正常に見えますが、ブラウザでは壊れているように見えます、その違いにより、ファイルを復元するか 一つのルールを修正するかが決まります。
強制切断と再接続の後に繰り返し、プラットフォームが起動時に状態を再適用する場合は再起動後にもう一度繰り返します。一部の構成は、すべてのライブ テストに合格しても、新しいルールが適用された最初の起動では失敗します。
窓を開けたドアを閉めてください
一時的な任意のソース管理ルール、使い捨てアカウント、拡張バインディング、寛容 DNS ルール、およびデバッグ ログを削除します。この削除自体が依存するパスの変更であるため、削除後にリモート側から新規接続テストを再実行してください。
再起動して実際のクライアントが再接続しても変更が反映されるまでエクスポートされたファイルを保持し、ウィンドウが開いている間に共有したものをすべて回転させます。次回の起動まで機能する構成は、どのルールが一時的であったかを誰も覚えていない 一週間後にルーターを失うことを静かに防ぐ方法です。
次の人が見る場所に変更を書き留めます、何が移動したか、どのファイルがそれを元に戻すか、どのパスがコンソールに到達するか、どのルールが一時的なものかなどを記録します。
VPN ページを開く前に、テストした復元フロー、証明した 二番目のパス、実際にアクセスできるエクスポート ファイル、および記述されたトリガーの 四つが存在する必要があります。不足しているものがあれば、まずそれを修正します。変更には 一 時間かかる場合があります、ロックアウトはできません。