私はいくつかのRaspberry Piを使ったホームラボをセットアップしています。アヴァヒサービスアナウンスメント用 - 個々の IP アドレスを覚える代わりに、 を使用して に ssh できますssh pi@<hostname>.local。特に、これはラップトップからだけでなく、Pi 自体からも機能することに注意してください。つまり、 に ssh された場合pi1、 を正常に実行できます。ssh [email protected]
私は最近、ワイヤーガードVPN自宅から離れていても自宅のラボにアクセスできるように、Piの1台で実行しています。このVPNをラップトップで使用すると、Piにsshで接続できますssh pi@<LAN-IP-address-of-pi>が、ないとssh pi@<hostname>.local。
それはなぜでしょうか? 私の (確かに基本的な) VPN の理解は、VPN は接続を「あたかも」VPN サーバーから発信されたかのように動作させることによって動作するというものです。それが事実なら、VPN 経由の SSH 動作が VPN サーバー自体からの SSH 動作と異なるのはなぜでしょうか? そうでない場合、何が間違っているのでしょうか?
私の直感では、DNS 解決は VPN 経由で行われません。VPN にdig pi.local接続されたラップトップと VPN サーバーの結果を比較すると、異なる結果が得られます (ネットワークとセキュリティについて十分な知識がないため、共有しても安全なものとそうでないものを判断することができないため、ペイロード全体を共有していません)。
- 私のラップトップから、
;SERVER行は参照します8.8.8.8（これは Google 所有の標準 DNS サーバーであり、LAN 上の私の Pi の IP アドレスを「知らない」はずです） - VPNサーバーからの
;SERVER行は、私のLANのLAN IPアドレスを参照しますパイホール
興味深いことに、どちらの応答にもANSWERセクションや Pi の実際の IP アドレスは含まれていません。
答え1
私の直感では、DNS解決はVPNを経由しないと思います
いずれにしても、mDNS (Avahi) には影響しません。名前は.local標準のユニキャスト DNS リゾルバを使用せずに、別の mDNS リゾルバによって解決されます。mDNS の重要な点は、DNS サーバーなしで動作することです。つまり、クエリ パケットをローカル サブネット全体にブロードキャストすることで動作します。
(技術的にはマルチキャストですが、リンク スコープなので、ローカル ブロードキャストと同じように扱うことができます。)
実際には得るべきではないどれでもPi-Hole が参照されている場合でも、からの「ANSWER」応答は返されませんdig whatever.local。Pi-Hole から応答が返された場合、それは Avahi/mDNS ではなく、通常の DNS です。(ホーム ルーターは、DHCP リース要求からホスト名を収集することでローカル DNS を実装しますが、DNS ドメインとして がある場合でも、通常は mDNS アドバタイズメントを収集しません。.localこれは、行うべきではありません。)
それはなぜでしょうか? 私の (確かに基本的な) VPN の理解は、VPN は接続を「あたかも」VPN サーバーから発信されたかのように動作させることによって動作するというものです。それが事実なら、VPN 経由の SSH 動作が VPN サーバー自体からの SSH 動作と異なるのはなぜでしょうか? そうでない場合、何が間違っているのでしょうか?
より一般的には、VPNはあなたをつなぐVPNサーバーと一緒にネットワークに接続します。インターネット上の仮想LANを形成するとも言えます。しない必ずしも接続を偽装したり、VPN サーバーに接続しているように見せかけたりする必要はありません。これは、必要に応じて別途行われます。(偽装は VPN 固有の機能ではなく、物理 LAN で使用される NAT とまったく同じです。)
(これが、OSI レイヤーの区別を除けば、VPN とプロキシの実際の違いです。プロキシ サーバーの主な目的は、リクエストを中継して、それらが「あたかも」プロキシから来たかのようにすることです。VPN の主な目的は、仮想ネットワークを構築することです。)
ほとんどのVPNタイプは、VPNサーバーの既存 ネットワークは、しかし、新しい1つは、VPNによって作成された「LAN」と物理的なLANの2つの別々のネットワークがあり、VPNサーバーがルーターとして物理ルーターeth0 eth1 eth2や LAN/WAN と同様に、VPN サーバーはeth0(LAN) とwg0(WireGuard VPN) の間をルーティングします。
ルータによって分離された2つの物理サブネットと同様に、2つのデバイス間で通常の（ユニキャスト）パケットを交換できますが、ルータは中継しません。ローカル放送サブネット間では、mDNS が使用するリンク スコープ マルチキャストをリレーしません。したがって、VPN クライアントが mDNS マルチキャスト クエリを送信すると、そのクエリは VPN クライアントと VPN サーバー間の「ローカル」サブネットまでしか送信されません。サーバーの wg0 インターフェイスから eth0 などを介して転送されることはありません。これを機能させるには、VPN サーバーはおそらく独自の avahi-daemon を「リレー」または「リフレクター」モードで実行する必要があります。このモードでは、受信した mDNS クエリを他のインターフェイスにプロキシし、応答を返します。
さらに、多くの VPN 接続は実際には Ethernet のような「ブロードキャスト対応」インターフェイスをエミュレートしないため、そもそもブロードキャスト パケットやマルチキャスト パケットの使用は不可能です。特に WireGuard は、一種の「ポイントツーマルチポイント」ネットワークを形成します。これは、内部的には 1 対 1 接続の集まりのようなものです。これらすべては単一の wg0 インターフェイスの背後に隠されていますが、内部的には AllowedIP を使用して各パケットを送信するピアを決定し、ブロードキャストやマルチキャストに対しても例外はありません。ほぼ同じことが、デフォルトの「tun」モードの OpenVPN (または「tun」インターフェイスを使用する他のほとんどのもの) にも当てはまります。
しかし、OpenVPNの「タップ」モードやTincやZeroTierなどのソフトウェアなどの他のVPNでは、するレイヤ2アドレスでイーサネットのようなネットワークをエミュレートし、より一般的な方法でマルチキャストやブロードキャストを処理できるようにします。実際、それらは主に通常のイーサネットをエミュレートするだけで、VPNサーバーは橋VPN と LAN インターフェイス間のルーティングではなく、それらのインターフェイスをルーティングします。「ブリッジ」VPN を設定すると、接続された VPN クライアントは実際にはローカル デバイスと同じ LAN サブネットの一部になり、自動的に互いの mDNS ブロードキャストを見ることができるようになります。
(また、欠点としては、互いの mDNS ブロードキャスト、ARP ブロードキャスト、Dropbox ブロードキャスト、UPnP/SSDP ブロードキャスト、NetBIOS ブロードキャスト、WS-Discovery ブロードキャスト、そして大量のバックグラウンド ノイズが見えることです。)