У меня есть домашняя лабораторная установка с несколькими Raspberry Pi, которые используютАвахидля объявления сервиса - я могу подключиться к ним по ssh ssh pi@<hostname>.localвместо того, чтобы запоминать отдельные IP-адреса. В частности, обратите внимание, что это работает не только с моего ноутбука, но и с самих Pi - то есть, если я подключен по ssh pi1, я могу успешно .ssh [email protected]
Недавно я создалVPN-защита Wireguardзапущенный на одном из Pi, чтобы позволить мне получить доступ к моей домашней лаборатории, даже когда я вдали от дома. При использовании этого VPN на моем ноутбуке, я могу подключиться к pi с помощью ssh ssh pi@<LAN-IP-address-of-pi>, нонетс ssh pi@<hostname>.local.
Почему так? Мое (признаюсь, базовое) понимание VPN заключается в том, что они работают, заставляя ваше соединение вести себя "как будто" оно исходит от VPN-сервера. Если это так, почему я должен получать другое поведение ssh через VPN, чем от самого VPN-сервера? Или, если это не так, то в чем его неправильность?
Интуиция подсказывает мне, что разрешение DNS не происходит через VPN — когда я сравниваю результаты dig pi.localс моего ноутбука, подключенного к VPN, и с VPN-сервера, я получаю разные результаты (не делюсь всей полезной нагрузкой, поскольку недостаточно разбираюсь в сетях и безопасности, чтобы знать, что безопасно делиться, а что нет):
- с моего ноутбука
;SERVERстрока ссылается8.8.8.8(я полагаю, что это стандартный DNS-сервер, принадлежащий Google, который, как и следовало ожидать, «не знает» об IP-адресе моего Pi в локальной сети) - с VPN-сервера
;SERVERстрока ссылается на IP-адрес моей локальной сетипи-отверстие
Интересно, однако, что ни один из ответов на самом деле не содержит ANSWERраздела или фактического IP-адреса Pi.
решение1
Моя интуиция подсказывает, что разрешение DNS не происходит через VPN.
Независимо от того, влияет ли это на mDNS (Avahi). Имена .localразрешаются отдельным преобразователем mDNS, а не стандартным преобразователем одноадресной DNS, и весь смысл mDNS в том, что он работает без DNS-серверов; он работает, широковещательно рассылая пакет запроса по всей локальной подсети.
(Технически это многоадресная передача, но поскольку она ограничена областью действия канала, можно сделать вид, что это то же самое, что и локальная трансляция.)
На самом деле вам не следует получатьлюбой"ANSWER" ответы из dig whatever.local, даже если ссылаются на Pi-Hole. В случае, если вы получаете ответ от Pi-Hole, это не Avahi/mDNS – это просто обычный DNS. (Домашние маршрутизаторы реализуют локальный DNS, собирая имена хостов из запросов аренды DHCP; но они обычно не собирают объявления mDNS, даже если у вас есть .localдомен DNS – чего делать не следует.)
Почему так? Мое (признаюсь, базовое) понимание VPN заключается в том, что они работают, заставляя ваше соединение вести себя "как будто" оно исходит от VPN-сервера. Если это так, почему я должен получать другое поведение ssh через VPN, чем от самого VPN-сервера? Или, если это не так, то в чем его неправильность?
В более общем смысле VPN работают по принципусоединяющий васв сеть вместе с VPN-сервером. Можно сказать, что они формируют виртуальную локальную сеть через Интернет. Онинеобязательно маскировать свои соединения или создавать видимость того, что вы подключаетесь «как будто» к VPN-серверу — это делается отдельно, если необходимо. (Маскарадинг не является специфической функцией VPN, это точно такой же NAT, который используется в физических локальных сетях.)
(В этом и заключается настоящая разница между VPN и прокси, помимо различия на уровне OSI. Основная цель прокси-сервера — ретранслировать запросы так, чтобы они приходили «как будто» от прокси. Основная цель VPN — построить виртуальную сеть.)
Большинство типов VPN не подключают вас напрямую к VPN-серверу.существующийсеть, однако, но создатьновый1. У вас есть две отдельные сети – созданная VPN «LAN» и физическая LAN – с действующим VPN-серверомкак маршрутизатормежду ними. Как и физический маршрутизатор eth0 eth1 eth2в LAN/WAN, ваш VPN-сервер осуществляет маршрутизацию между eth0(LAN) и wg0(WireGuard VPN).
Так же, как и в случае с двумя физическими подсетями, разделенными маршрутизатором, эти два устройства могут обмениваться обычными (одноадресными) пакетами, но маршрутизатор не будет их ретранслировать.местные трансляциимежду подсетями, и не будет ретранслировать многоадресные рассылки в области ссылок, которые использует mDNS. Поэтому, когда ваш VPN-клиент отправляет многоадресный запрос mDNS, он доходит только до «локальной» подсети между VPN-клиентом и VPN-сервером. Он никогда не пересылается с интерфейса сервера wg0 через eth0 или что-либо еще. Чтобы это работало, VPN-серверу, вероятно, потребуется запустить собственный avahi-daemon в режиме «ретрансляции» или «рефлектора», где он проксирует полученные запросы mDNS на другие интерфейсы и отправляет ответы обратно.
Кроме того, многие VPN-подключения на самом деле не эмулируют интерфейс с возможностью "широковещательной передачи", такой как Ethernet, что делает использование широковещательных и многоадресных пакетов невозможным изначально. WireGuard, в частности, формирует своего рода сеть "точка-многоточка", где она больше похожа на кучу соединений "один к одному" под капотом - все они скрыты за одним интерфейсом wg0, но внутри она использует AllowedIPs, чтобы решить, какому пиру отправлять каждый пакет, и не делает исключений для широковещательных или многоадресных рассылок. Примерно то же самое относится к OpenVPN в его стандартном режиме "tun" (или к большинству других, использующих интерфейсы "tun").
Но некоторые другие VPN, такие как OpenVPN в режиме «tap», а также программное обеспечение, такое как Tinc или ZeroTier,делатьэмулируют сеть типа Ethernet с адресацией уровня 2, что позволяет им обрабатывать многоадресные и широковещательные рассылки более традиционным способом. Фактически, они в основном просто эмулируют обычный Ethernet, позволяя VPN-серверумостинтерфейсы VPN и LAN вместо маршрутизации между ними. Если вы настроите VPN-мост, то подключенные VPN-клиенты фактически станут частью той же подсети LAN, что и локальные устройства, и автоматически смогут видеть трансляции mDNS друг друга.
(Недостатком также является то, что они будут видеть трансляции mDNS друг друга, а также трансляции ARP, трансляции Dropbox, трансляции UPnP/SSDP, трансляции NetBIOS, трансляции WS-Discovery и массу фонового шума.)