나는 몇 가지 Raspberries Pi를 사용하는 홈랩 설정을 가지고 있습니다.아바히ssh pi@<hostname>.local서비스 공지를 위해 - 개별 IP 주소를 기억할 필요 없이 SSH로 접속할 수 있습니다 . 특히 이것은 내 노트북뿐만 아니라 Pis 자체에서도 작동한다는 점에 유의하세요. 즉, ssh로 연결하면 pi1성공적으로 할 수 있습니다 .ssh [email protected]
나는 최근에와이어가드 VPN집 밖에서도 내 홈랩에 액세스할 수 있도록 Pis 중 하나를 실행합니다. 내 노트북에서 이 VPN을 사용할 때 를 사용하여 ssh로 파이에 연결할 수 ssh pi@<LAN-IP-address-of-pi>있지만~ 아니다와 함께 ssh pi@<hostname>.local.
왜 그런 겁니까? VPN에 대한 나의 (기본적으로) 이해는 연결이 VPN 서버에서 시작된 것처럼 "마치" 작동하도록 하여 작동한다는 것입니다. 그렇다면 VPN 서버 자체에서와 VPN을 통해 다른 SSH 동작을 얻는 이유는 무엇입니까? 아니면 그렇지 않다면 어떻게 잘못된 것입니까?
내 직관으로는 DNS 확인이 VPN을 통해 진행되지 않는다는 것입니다. VPN으로 연결된 노트북과 VPN 서버의 결과를 비교할 때 dig pi.local다른 결과를 얻습니다(충분히 알지 못하기 때문에 전체 페이로드를 공유하지 않음). 공유해도 안전한 것과 그렇지 않은 것을 파악하기 위한 네트워킹 및 보안):
- 내 노트북에서
;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 서버 없이 작동한다는 것입니다. 쿼리 패킷을 전체 로컬 서브넷에 브로드캐스팅하는 방식으로 작동합니다.
(기술적으로는 멀티캐스팅이지만 링크 범위이므로 로컬 브로드캐스트와 동일한 척할 수 있습니다.)
실제로는 받지 말아야 할어느dig whatever.localPi-Hole이 참조되는 경우에도 "ANSWER" 응답이 발생합니다 . Pi-Hole로부터 응답을 받은 경우에는 Avahi/mDNS가 아니라 일반 DNS입니다. (홈 라우터는 DHCP 임대 요청에서 호스트 이름을 수집하여 로컬 DNS를 구현하지만, DNS 도메인을 갖고 있더라도 일반적으로 mDNS 광고를 수집하지 않습니다. 수집 .local해서는 안 됩니다.)
왜 그런 겁니까? VPN에 대한 나의 (기본적으로) 이해는 연결이 VPN 서버에서 시작된 것처럼 "마치" 작동하도록 하여 작동한다는 것입니다. 그렇다면 VPN 서버 자체에서와 VPN을 통해 다른 SSH 동작을 얻는 이유는 무엇입니까? 아니면 그렇지 않다면 어떻게 잘못된 것입니까?
그보다 더 일반적으로 VPN은 다음과 같이 작동합니다.당신을 연결VPN 서버와 함께 네트워크에 연결됩니다. 인터넷을 통해 가상 LAN을 형성한다고 말할 수 있습니다. 그들~하지 않다반드시 연결을 가장하거나 VPN 서버에 "마치" 연결하는 것처럼 보이게 만드세요. 필요한 경우 별도로 수행됩니다. (매스커레이딩은 VPN 전용 기능이 아니며 물리적 LAN에 사용되는 NAT와 정확히 동일합니다.)
(이것이 OSI 계층 구별을 제외하고 VPN과 프록시의 실제 차이점입니다. 프록시 서버의 주요 목적은 요청이 프록시에서 "마치" 온 것처럼 요청을 전달하는 것입니다. VPN의 주요 목적은 가상 네트워크를 구축하는 것입니다.
대부분의 VPN 유형은 사용자를 VPN 서버에 직접 연결하지 않습니다.기존의하지만 네트워크를 생성하세요.새로운하나. VPN이 만든 "LAN"과 물리적 LAN이라는 두 개의 별도 네트워크가 있으며 VPN 서버가 작동합니다.라우터로서사이. 물리적 라우터에 LAN/WAN이 있는 것처럼 eth0 eth1 eth2VPN 서버도 eth0(LAN)과 wg0(WireGuard VPN) 사이를 라우팅합니다.
라우터로 분리된 두 개의 물리적 서브넷과 마찬가지로 두 서브넷은 장치 간에 일반(유니캐스트) 패킷을 교환할 수 있지만 라우터는 릴레이하지 않습니다.지역 방송mDNS가 사용하는 링크 범위 멀티캐스트를 중계하지도 않습니다. 따라서 VPN 클라이언트가 mDNS 멀티캐스트 쿼리를 보내면 VPN 클라이언트와 VPN 서버 사이의 "로컬" 서브넷까지만 이동합니다. 서버의 wg0 인터페이스에서 eth0 등을 통해 전달되지 않습니다. 이 작업을 수행하려면 VPN 서버가 수신된 mDNS 쿼리를 다른 인터페이스로 프록시하고 응답을 다시 보내는 "릴레이" 또는 "리플렉터" 모드에서 자체 avahi-daemon을 실행해야 할 것입니다.
또한 많은 VPN 연결은 실제로 이더넷과 같은 "브로드캐스트 가능" 인터페이스를 에뮬레이션하지 않으므로 애초에 브로드캐스트 및 멀티캐스트 패킷 사용이 불가능합니다. 특히 WireGuard는 일종의 "지점 대 다중 지점" 네트워크를 형성합니다. 여기서는 내부적으로 여러 개의 일대일 연결과 유사합니다. 모든 연결은 단일 wg0 인터페이스 뒤에 숨겨져 있지만 내부적으로는 AllowedIP를 사용하여 결정합니다. 각 패킷을 어느 피어로 보낼 것인지, 브로드캐스트나 멀티캐스트에도 예외는 없습니다. 기본 "tun" 모드(또는 "tun" 인터페이스를 사용하는 대부분의 다른 모드)의 OpenVPN에도 거의 동일하게 적용됩니다.
그러나 "탭" 모드의 OpenVPN과 Tinc 또는 ZeroTier와 같은 소프트웨어와 같은 일부 다른 VPN은하다레이어 2 주소 지정을 통해 이더넷과 유사한 네트워크를 에뮬레이션하여 보다 일반적인 방식으로 멀티캐스트와 브로드캐스트를 처리할 수 있습니다. 실제로 그들은 대부분 일반 이더넷을 에뮬레이트하여 VPN 서버가 다음을 수행할 수 있도록 합니다.다리VPN과 LAN 인터페이스 사이를 라우팅하는 대신 "브리지" VPN을 설정하면 연결된 VPN 클라이언트는 실제로 로컬 장치와 동일한 LAN 서브넷의 일부가 되며 자동으로 서로의 mDNS 브로드캐스트를 볼 수 있습니다.
(또한 단점은 서로의 mDNS 브로드캐스트, ARP 브로드캐스트, Dropbox 브로드캐스트, UPnP/SSDP 브로드캐스트, NetBIOS 브로드캐스트, WS-Discovery 브로드캐스트 및 수많은 배경 소음을 볼 수 있다는 것입니다.)