2つのVPNクライアントを介して接続する
ラップトップで2つのVPNクライアントを介して接続すると、正確にはどうなりますか？たとえば、Cisco Any Connectを使用して接続し、別のVPNクライアント（HotSpot ShieldやproXPNなど）を使用して別のトンネルを介して接続します。
実際のデータは最初のサーバー/サイトで復号化され、平文/可視になりますか？つまり、これは起こります：データは私のラップトップで暗号化され、サーバー1に送信され、復号化されてから、暗号化されてサーバー2に送信され、最終的に復号化されます。 2番目のトンネルはサーバー1からサーバー2ではなくクライアントからサーバー2を経由しているため、私はそれを疑っています。
それともトンネルの中のトンネルでしょうか？つまり、データは私のラップトップで2回暗号化およびカプセル化され、サーバー1で復号化されますが、まだプレーンテキストではなく、サーバー2にルーティングされて最終的に復号化されます。
または、ラップトップは通常のクライアントからサイトへのVPNに対して1つのトンネル（後者？）を選択するだけですか？それとも、2番目に接続されたものが最初から確立されていませんか？
典型的なVPNクライアントは次のように機能します。サーバーに接続し、オペレーティングシステムに、送信されるすべてのパケットを提供するように指示します。特定のセット内の任意のアドレス。たとえば、VPNクライアントが、10.0.0.0/8宛てのすべてのパケット（つまり、「10」で始まるすべてのIPアドレス）を処理する必要があることをアドバタイズすると仮定します。 OSは、アドレス "u.v.w.x"に向かうパケットを検出すると、 "u"が "10"であるかどうかを確認します。はいの場合、それはパケットをVPNに渡します。VPNはそれと魔法をかけ、高度な暗号化/ MAC /何でもサーバーに転送します。それ以外の場合、OSがVPNクライアントなしで実行するのと同じように、パケットは「インターネットに」送信されます。
このシステムの実装方法の詳細は、VPNの実装に依存します（たとえば、特定の「ルート」を宣言することがあります。または、ファイアウォールルールですべての送信パケットを傍受し、対象のパケットをリダイレクトすることもできます; ...）。
2つのVPNクライアントがあり、それらの「アドバタイズされたアドレスのセット」が重複しない場合、それらはうまく機能する可能性がありますIPレベルで：それぞれが独自の仮想ネットワークのパケットを取得します。他のパケットはそのままにしておきます。ただし、「傍受リソース」を争って、最初のVPNクライアントが完全に非アクティブになる可能性もあります。
一方、両方のVPNが重複するアドレスのセットをアドバタイズする場合、問題はほぼ保証されます。運がよければ、2番目のVPNは明示的なメッセージを表示して実行を拒否します。そうしないと、クライアントの1つが断続的に優先される可能性があり、奇妙で混乱を招きます。おそらく、1つのVPNサーバーがother VPNの原因であったパケットを受信するため、重大なデータリークが発生します。
DNSでトラブルが発生します。アプリケーションと人間はIPアドレスではなくホスト名を扱います。 DNSはホスト名をIPアドレスに変換します。 VPNは「仮想プライベートネットワーク」であり、世界中のインターネットDNSからは見えない名前を使用しています。したがって、VPNクライアントはIPパケットだけでなく名前解決システムもインターセプトし、名前解決要求の一部（すべてではない）をVPN上の専用DNSサーバーにリダイレクトします。
2つのVPNクライアントがそのリダイレクトを競います。事柄可能性クライアントが一部のドメインのリクエストのみをリダイレクトできれば、うまく機能します。しかし、可能性は、ヒジンクが続くことです。 1つのVPNの一部の名前は、おそらくIPアドレスに変換できなくなり、機能が制限されます。おそらく、1つのVPNがother VPNの名前解決を受信するため、機能が壊れるだけでなく（1つのVPNのDNSが他のVPNの名前をどうするかわからないため）、一部のプライベート1つのVPNから別のVPNへのデータリーク（ホストnamesは非常に機密性が高いことはめったにありませんが、それでもリークです）。
この最後の状況では、他のVPNのプライベート名の名前解決要求を受信するVPNは、偽造されたDNS応答で応答し、他のVPNからのトラフィックをすべて自分自身にリダイレクトする理想的な位置にあります。
だからそれをしないでください。複数のVPNクライアントを同時に実行すると、トラブル、診断が困難な障害、潜在的なデータリークの原因となります。
複数のVPNの問題を回避するには、より「制御された」形式のVPNを使用するように努力する必要があります。たとえば、sshを使用したSOCKSプロキシです。これにより、すべてのトラフィックを別のホスト（「VPNサーバー」）にリダイレクトするWebブラウザーを実行し、マシンの残りの部分（および他のブラウザーインスタンス）は変更せずに残すことができます。たとえば この答え を参照してください。一部の純粋主義者は、そのようなプロキシはnot VPNであると言いますが、多くの実際的な目的（実際にはWebベースのもの）では、これは機能的に同等です。ポートベースのトンネルの代替案もご覧ください。
私はかつてそれを何度も行っていました（12か所ほどのポートベースのトンネルとSOCKSプロキシーもあり、すべてうまくいきました）。 SOCKSソリューションは名前解決にも有効です。Webブラウザーからの名前解決要求は、ローカルDNS構成に触れることなく、トンネルを通過して、反対側（つまり、VPN）で解決されます。ポートベースのトンネルでは、静的ローカル名の宣言が必要です。
たとえば、Cisco Any Connectを使用して接続し、別のVPNクライアント（HotSpot ShieldやproXPNなど）を使用して別のトンネルを介して接続します。
私は1台のコンピューターで両方のクライアントを使用していると想定しているため、2つの並列トンネルがあり、一方が他方の内部にあるわけではありません（コンピューターからServer1に接続した場合のように、thereServer2とServer1を接続するためにVPN2を起動しました。
最初の（並列）シナリオでは、各VPNクライアントが独自の仮想インターフェイスを作成し、独自のアドレス、ネットマスク、リモートゲートウェイ、および関連するルーティングを使用します。
/トンネルを介して送信されたデータは、そのトンネルによって暗号化され、それ以外は暗号化されないため、問題は次のようになります。コンピューターはwhatdata send downwhichトンネル？
これは、クライアントのルーティングルールを通じて行われます。たとえば、VPN1でアドレス192.168.42.17/24を受け取り、VPN2でアドレス192.168.77.13/24を受け取る場合があります。ホスト.42.33とリンクしようとすると、VPN1を経由し、VPN2はそれを何も認識しません。
ここで、192.168.42.0/24は、ユーザーとサーバーの間で使用されるプライベートネットワーク、つまり、Server1によってすべてのVPNクライアントに割り当てられたものにすぎない場合があります。 Server1が提供する実際のネットワークは10.20.30.0/24である可能性があるため、Server1はalso192.168.42.1を介して10.20.30.0/24へのルーティングを追加します。その後、10.20.30.137に接続しようとすると、その接続はVPN1を経由して流れ、暗号化されます。また、VPN2はこれが行われていることさえ認識しません（なぜそれが必要なのでしょうか？）。
考えられる問題：bothVPN1とVPN2が同じ物理ホストに対応しない同じサブネットのルートをブロードキャストするとどうなりますか？たとえば、まったく同じ構成の2つのオフィスがあり、ServerAtOffice1のアドレスが10.20.30.137で、ServerAtOffice2のアドレスが10.20.30.195であるとします。これらの2つのネットワーク決して互いに対話しないなので、これにより競合がまったく発生しなくなります。
10.20.30.0がVPN1を通過することを通知するVPN1を起動するまで、次に10.20.30.0がVPN2を経由して他の誰も実行しないことを通知するVPN2も起動します。
その場合に何が起こるかは、VPNクライアントによって異なります。スマートクライアントは「ねえ、10.20.30.0をルーティングしようとしていましたが、何を知っていますか？このルートはすでにどこか別の場所にあります。おそらく、何か厄介な」。
または、2つの愚かなクライアントがあり、他のクライアントの構成要求を上書きする最後の方が利益を生む可能性があります。
または、さらに奇妙なことが続き、接続がstart動作して、数パケット後に乱雑に死ぬ場合があります。
最後の可能性は、両方のクライアントが自分自身を介してdefaultルート（知らないアドレスに1つ）を設定することです。
次に、Server1に接続すると、すべてのインターネットナビゲーションがServer1を介して暗号化されます。次に、alsoVPN2を起動すると、「デフォルト」のナビゲーションがVPN2経由でルーティングされます。これで、お客様＃1に関するすべてのGoogleクエリが、明確に、お客様＃2のネットワーク、ファイアウォール、パケットアナライザーなどにルーティングされます。これは、あなたの役割と2人の顧客の条件の友好性に応じて、トラブルの終わりを意味しません。
微調整
2つのクライアントを並行して実行せずに、他のバージョンを実行するにはどうすればよいですか？ PPTP VPNサーバーが実行されているルーターALPHAでDD-WRTを実行している場合、
クライアントCHARLIEから接続する相手
vPNサーバーBRAVOに接続できますか？それはトンネリングの連鎖ですか？いずれにせよ、最終的なサーバーは、ルーターからのトラフィックをその間に見ます。 -ラースロー
ここには2つのシナリオがあります（マシンに名前を追加しました）。
最初のシナリオでは、ALPHAはそれ自体ですまたはサーバーBRAVOのクライアントDELTA。この場合、CHARLIEからのパケットは通常、サーバーALPHAによってmasqueradedになるため、BRAVOのサービスを受けるクライアントは、パケットがDELTAからのものであると見なします。これは、BRAVOのクライアントがALPHAのクライアントと同じスキームを持っている場合、実行が困難または不可能になる可能性があります。その場合、たとえば、アドレス192.168.112.17を持つユーザーが不明確になる可能性があります。 ALPHAの17番目のクライアントですか、それともBRAVOの17番目のクライアントですか？
2番目のシナリオでは、ALPHAはルーティングのみを行うため、ALPHAのVPNを介してBRAVOを利用できます。つまり、最初のVPNトンネル内の2番目のVPNトンネルを開き、BRAVOによって2番目のIPアドレスが割り当てられます。これで、同時にサーバーALPHAのクライアントCHARLIEおよび（ALPHAには不明）の両方のクライアントDELTAがサーバーBRAVOになります。
BRAVOのクライアントはあなたをDELTAとみなしますが、BRAVOはもちろんあなたがALPHAのクライアントCHARLIEであることを認識します。
ここでも、アドレスとルーティングが競合する場合は問題が発生する可能性があります（たとえば、BRAVOへの接続がデフォルトルートに依存している、しかし、BRAVO自体が接続時に独自のデフォルトルートをインストールする、 1つをALPHAで置き換えます）。
また、（今日、これが無関係になったとしても）この2番目のシナリオでは、ALPHAの負荷は低くなり、CPUの負荷は比例して高くなります（BRAVOのネットワークへのすべてのパケットは、BRAVO-Driverによって暗号化され、ALPHA-Driverに渡されますおよびreencrypted、最終的にADSLドライバーに渡され、途中で送信されます）。
理論的には、トンネル内のトンネルになります。最初のトンネルは、コンピューターと最初のVPNエンドポイントの間にあります。 2番目のトンネルは最初のトンネルを通過して最初のVPNエンドポイントに到達し、最初のトンネルを出てから2番目のVPNエンドポイントに到達します。
VPNクライアントが接続とルーティングテーブルを設定する方法に依存すると思うので、理論的に言っています。 2番目のVPNクライアントはルーティングテーブルとメトリックを設定することができます。これにより、上からトンネルの理論的なセットアップでトンネルが確立されている場合でも、データは最初のトンネルに送信され、2番目のトンネルはまったく使用されません。
2つのケース、2つの可能性：
クライアント接続を開始できますfrom yourlaptopto（Cisco、2番目の接続よりfrom theCiscoto最終的なターゲット：
<laptop> ---- <Cisco> ... <Cisco> ---- <final>
この場合、データはCiscoホストで平文で転送されます。
または、クライアント接続を開始することもできますfrom yourlaptopto（Cisco、2番目の接続よりfrom yourlaptopto最終的なターゲット：
<laptop> ---- <Cisco> .... <final>
<laptop> ----------------- <final>
この場合（両方の暗号化トンネルが同じホストから連続して開始されます：（laptop））、それはtunnel within a tunnelおよびCiscoは暗号化されていないデータを表示しません。
Nota：これで、
---- mean encrypted connection and
.... mean unencrypted (local or network) connection