あなたは今いるトンネルについてどれくらい知っていますか？

みなさんこんにちは。私は次男です。

トンネルは中国語に翻訳されています。日々の開発の中で、私たちは多かれ少なかれこの言葉に遭遇するでしょう。

まず、実際の例を参考にしてトンネルの役割を見てみましょう。

西安・成都高速鉄道は北は西安から始まり、南は成都で終わります。路線の全長は643キロメートルで、設計速度は時速250キロメートルです。古代から、豊穣の地に入ることは極めて困難な仕事でした。四川省は山々に囲まれており、どの方向からも入るのが困難です。西安と成都の間には秦嶺山脈という自然の障壁があることは知られています。高速鉄道は飛行機のようにその上を飛ぶことはできません。速度と対気速度の両方を達成する唯一の方法は、秦嶺山脈の間にトンネルを掘り、そのトンネルを通じて高速鉄道を秦嶺山脈を通過させることです。

私たちのオンラインの世界に来てください。リモート サーバーにアクセスしたいのですが、残念ながら、リモート サーバーとの間にファイアウォールが存在します。このファイアウォールは、国中に広がる秦嶺山脈のようなものです。それを避ける方法はありません。それで、私たちに何ができるでしょうか?

このとき、トンネルを使用する必要があります。トンネルの概念を理解するのは難しくありません。注目すべき 2 つの特徴があります。

• データを中継するには仲介者の助けが必要です。これは理解しやすいですね。通信する両者が直接接続できる限り、他者に頼る必要はありません。
• この仲介者は、以下で説明する HTTPS プロキシなどのユーザー モード アプリケーション、または前に説明した flannel.1 に基づく VXLAN などのカーネル モード モジュールである可能性があります。
• ほとんどのアプリケーション シナリオでは、仲介者によって中継されるデータは暗号化されるため、仲介者はパイプラインの役割に退化し、データ スニッフィングの機能がなくなります。データが暗号化されずに渡されるトンネルの例としては、Flannel VXLAN モードがあります。

これまで頻繁に使用してきたトンネルを見てみましょう。

• HTTPS プロキシに関係するトンネル。これは、HTTPS プロキシを介してクライアントとサーバーの間でデータを継続的に中継することによって実現されます。
• SSH トンネル。これは、ファイアウォールでポート 22 を開くことによって実現されます。もちろん、ファイアウォールがポート 22 を閉じている場合、このトリックは失敗します。
• VPN トンネル。
• フランネル VXLAN モードに基づいて実装された K8s オーバーレイ ネットワーク モデル。

一つずつ見ていきましょう。

HTTPS プロキシ トンネル

HTTPS プロキシについて話すときは、まず HTTP プロキシについて言及する必要があります。図 1 に示すように、HTTP プロキシは仲介者のようなものです。

• クライアント ブラウザーは TCP 接続を開始し、アクセスする必要がある実際の Web サービスを GET および HOST HTTP ヘッダーに配置します。
• リクエストを受信すると、HTTP ヘッダーを解析し、実際の Web サービスへのリクエストを開始します。
• その後、Web サービスから返されたコンテンツをクライアントに返します。

上記のプロセスでは、HTTP プロキシは 2 つの TCP 接続を同時に維持します。クライアントとサーバー間の会話の内容を非常に明確に把握しているため、セキュリティ上のリスクが生じます。さらに、悪質なプロキシの中には、サーバーから返される HTML ページに迷惑な広告を追加するものもあります。

図1: HTTPプロキシ

時代は変わり、技術は変わり、そして需要も変わります。現在、ほとんどのウェブサイトは HTTPS を使用しています。この時点で HTTP プロキシを使用すると、プロキシのみが Web サービス証明書を表示でき、クライアントはプロキシ証明書しか受信できないという問題が発生します。明らかに、プロキシ証明書内の名前は、クライアントがアクセスしようとするアドレスとはまったく異なります。このとき、ブラウザは容赦なく警告を発し、TLS ハンドシェイクは成功しません。

この問題を解決するために、HTTPS プロキシが誕生しました。図 2 にそのワークフローを示します。

① クライアントブラウザは最初にHTTPSプロキシへのTCP接続を開始しますが、HTTPリクエストではCONNECTメソッドが使用されます。

② この接続を受信すると、HTTPS プロキシは CONNECT リクエストのデータを使用して google.com への TCP 接続を開始します。

③ 今後、HTTPS プロキシはクライアントと google.com 間のデータの中継のみを担当します。 TLS ハンドシェイク プロセスにまったく参加しないため、解析は行われず、解析する方法もありません。中継されるデータには、TLS ハンドシェイク データ パケット (証明書、暗号化アルゴリズム、暗号化キーなど) と暗号化された HTTP ペイロードが含まれます。

ステップ ③ では、HTTPS プロキシはクライアントとサーバーのセッション データを透過的に転送することでトンネル効果を実現します。

上記のプロセスでは、ブラウザが最初から最後まで google.com と直接 TCP 接続を開始することはなく、通信する 2 つの当事者間のすべてのデータは HTTPS プロキシを介して転送されたことを強調しておく必要があります。

図2: HTTPSプロキシを介してクライアントとサーバーが直接トンネルを作成する

図 3 と 4 は、クライアントと HTTPS プロキシが CONNECT メソッドを通じて TLS トンネルを作成するプロセスを明確に示しています。

図3: CONNECTメソッドによるTLSトンネルの作成

図4: CONNECTメソッドを使用してTLSトンネルを作成するパケットキャプチャ

SSHトンネル

調査の結果、ファイアウォールのせいでクライアントとサーバーは直接通信できないものの、ファイアウォールはポート 22 に対して開いているという朗報があることがわかりました。

ポート 22 にアクセスするネットワーク パケットにペイロードとしてリクエストを配置すると、このファイアウォールを通過できなくなりますか?

図 5 に示すように、これはファイアウォールからトンネルを掘るようなものです。写真の中に、SSH トンネルを通過している長い赤い帯が見えますか?秦嶺トンネルを通過する高速列車のように見えますか？

もちろん、このネットワーク パケットの受信側は、ポート 22 でリッスンしている SSH サーバーです。ネットワーク パケットを受信した後に何を実行するかは問題ではありません。重要なのは、リクエストがファイアウォールを正常に通過し、配信されたことです。それだけでなく、SSH に組み込まれたセキュア サポートのおかげで、データは暗号化された形式で配信されます。 1つ買うと1つ無料という感じでしょうか?

図5: SSHトンネルを使用してファイアウォールを介してデータを渡す図

さて、SSH サーバーがデータを受信した後に何を行うかを知ることも重要です。図5は単なる概略図である。私はいつもその背景にある詳細を皆さんに説明したいと思っています。この例では、ローカル クライアントは実際にサービス 192.168.4.23:32020 にアクセスしようとしています。もちろん直接アクセスすることはできません。

• SSH クライアントは localhost:9300 でリッスンしています。
• クライアントが localhost:9300 にアクセスすると、アクセス要求は実際には SSH クライアントによってカプセル化され、SSH トンネルを介して SSH サーバーに送信されます。 SSH サーバーは 192.168.5.24:22 でリッスンしています。
• 次に、SSH サーバーは 192.168.4.23:32020 への要求を開始します。

図6: SSHトンネル経由でファイアウォールを通過するリクエストの詳細

私の2番目の兄は、「Podコンテナをリモートデバッグする方法」という記事で、SSHトンネルの使用シナリオを詳しく説明しました。

仮想プライベートネットワーク

「TUN デバイスの魔法のような使用 - VPN」および「TUN デバイスの魔法のような使用 - OpenVPN の完全なプロセス補足」という記事で、私の次男は、VPN の動作原理と、クライアントが VPN を介して企業の内部サービスに要求を開始するときに必要な特定のプロセスを詳しく説明しました。添付写真は以下の通りです、詳細は省略します。

図7: ブラウザがVPN経由で社内の企業サービスにアクセスする

フランネルVXLAN

私は冷酷な人間なので多くは語りませんが、「​​tun デバイスの素晴らしい使用法 - Flannel UDP モード​​」という記事を添付します。

比較の概要

HTTPS プロキシ トンネルと SSH トンネルは、比較的制限された方法でクライアントとサーバー間の方向性のあるトンネルのみを確立しますが、VPN トンネルは企業内のドアを直接開きます。理論上は、クライアント側で VPN が DNS キャッシュへのアクセスとアプリケーションのルーティングを許可するように構成されている限り、クライアントは社内にいる場合と同じように自由に企業の内部サービスにアクセスできます。

図8: VPNトンネルと他の2つのトンネルでアクセス可能なサービスの粒度の比較

使いやすさの観点から言えば、もちろん VPN が最適です。 VPN 認証に合格すれば、クライアントから社内ネットワークへの扉を完全に開くことに相当します。企業のセキュリティの観点から見ると、VPN は最も粒度が粗く、安全性の低い方法です。