リモートアクセスかサイト間VPNか、どちらが適切か
リモートアクセスのトンネルは機器をネットワークにつなぎ、サイト間トンネルはゲートウェイ同士をつなぎます。トポロジーで設計を選び、障害を絞り込みます。
出張中の社員と支社では必要なトンネルが異なり、選び間違えると実験室では動くのに最初の月曜日に失敗する設計になります。リモートアクセスは機器をゲートウェイにつなぎます。サイト間は、ネットワークを表す二つのゲートウェイをつなぎます。以下のチェックリストが、要件が実際にどちらを指しているかを決めます。
誰がダイヤルし、ダイヤルする側の背後に何があるか
リモートアクセスでは、ノートPCやスマートフォンのソフトウェアがトンネルを確立し、ゲートウェイはアドレスとルートを割り当てる前に利用者、機器、またはその両方を認証します。サイト間では、ルーター、ファイアウォール、クラウドゲートウェイが接続を確立し、その背後の機器はクライアントを動かす代わりに通常のルーティングを使います。前者では社員の機器、後者では管理された機器という違いが、トンネルの稼働責任を誰が持つかを決めます。認証が人を表すのかネットワークを表すのかも、この違いが決めます。
ある拠点のすべてのマシンが、機器ごとの設定なしに別の拠点へ届くことが要件なら、ここで止まります。それはサイト間であり、リモートアクセスのログインを山ほど並べても代わりになりません。
アドレッシングと戻りの経路
ローカルとリモートの範囲を別々に計画します。二つの拠点が同じプライベートサブネットを使うこともあり、その場合はルーティングが曖昧でなくなる前に変換か再採番が必要です。本社と同じ範囲を使う家庭用ルーターは、一人の在宅勤務者に同じ問題を起こします。重複はよくあることなので、その確認は最初の会話に含めるべきです。
戻りの経路は往路と同じだけ重要です。サーバーは要求を受け取っても、クライアントネットワークへ戻るルートを持たないことがあります。
どのルーターがリモートプレフィックスを知っているかを、クラウドネットワークや複数のゲートウェイでは特に重要なので文書化します。緑のトンネルアイコンは、宛先に有効な戻り経路があるかを答えられず、片方向のpingも同じです。リモートアクセスでは通常ゲートウェイがプールのルートを持ち、サイト間ではプレフィックスを運ぶすべての中間ルーターが合意する必要があります。変換は、アドレスを埋め込むアプリケーションが壊れるまで欠けたルートを隠せます。
インターネットへの出口は別の決定です
プライベートな到達性は、トンネルが一般のブラウジングを運ぶことを要求しません。通常のウェブ通信がゲートウェイから出るかどうかは二つ目の決定で、設計ごとに決めてクライアントプロファイルか拠点の設定に記録します。
フルトンネルとスプリットトンネルはその問いへの答えであり、リモートアクセスかサイト間かという問いへの答えではありません。内部名にはどちらの設計でも適切なDNSが必要で、公開リゾルバーは社内オフィスのホスト名に答えを持ちません。リゾルバーを配ることと既定ルートを配ることは関連する設定であり、片方だけを変えるとDNSの問題に見える障害が生じます。
トポロジーで障害を絞り込みます
持ち歩くノートPCが一台上がクライアント、そのアカウント、またはローカルネットワークでアクセスを失います。拠点全体では共有パスとゲートウェイでアクセスを失います。
まずトンネルの確立、次にルート、次に許可された通信、次に名前解決、次にアプリケーションのログインを確認し、失敗した最初の段階で止めます。ip route get 10.60.8.15 アプリケーションのログを一行も読む前に、ルーティングの問いに答えます。暗号化の設定はファイル共有の権限エラーを直さず、動くpingはアプリケーションが認可されていることを証明しません。順序を固定すると、一つの障害を三つに変える場当たり的な設定変更を防げます。
最後に、ベンダーの資料を読むときは定義をまっすぐ保ち、商用のインターネット出口サーバーは企業のプライベートゲートウェイとは別のサービスであり、その企業のネットワークへのアクセスを一切与えないことを忘れないでください。