VPN на хоста или във виртуалната машина? Наръчник за решение
Собственикът на тунела решава какво какво покрива. Изберете разположение на хоста или на госта, после го потвърдете с проверки на маршрута, DNS и изхода вътре в госта.
Изграждането на тунела вътре в госта и изграждането му на хоста и в двата случая променят адреса, който браузърът съобщава, и точно там приликата свършва. Тунелът, собственост на госта, пази ключовете си, маршрута си по подразбиране и резолвера си в ядрото на госта, докато хостът препраща шифровани пакети към един отдалечен адрес. Тунелът, собственост на хоста, е огледален образ: клиентът на хоста държи сесията и прилага маршрути и политика, а гостът заема каквото излезе. Изберете грешния собственик и всеки следващ симптом ще ви отведе до грешната машина. Две команди решават въпроса за около минута, а останалото от този наръчник е какво да правите с отговора.
Решете кой е собственикът, преди да пипате клиента
Правилото е за това къде се произвежда шифротекстът, а не коя машина показва икона за VPN. Ако гостът го произвежда, на госта му трябва работещ маршрут до VPN сървъра и нищо друго от хоста. Ако хостът го произвежда, на госта му трябва пътят през хоста да оцелее при всяка политика, която клиентът на хоста налага върху локалния трафик.
Три въпроса обикновено избират разположението вместо вас. Трябва ли трафикът на госта да оцелее при корпоративен клиент на хоста? Тогава тунелът е в госта. Трябват ли на няколко госта едни идентификационни данни и един адрес за изход? Тогава той е на хоста, с умишлено настроено препращане. Трябва ли трафикът на госта да остане напълно извън VPN на хоста? Тогава тунелът в госта е единствената подредба, която ви дава това по конструкция.
Запишете отговора като един ред до името на VM: guest-owned или host-owned. В лаборатория от шест машини тази бележка спестява повече време от всяка стъпка по-долу, защото ви спира да търсите проблем в тунел, който никога не е бил в машината, на която сте влезли.
WSL1 и WSL2 са противоположни случаи
WSL1 не е виртуална машина, затова въпросът за разположението до голяма степен изчезва. Неговите Linux двоични файлове работят срещу мрежовия стек на Windows през слой за транслация и Linux VPN клиентът няма независими интерфейси за настройка. Работещата подредба е тунел от страната на Windows, като дистрибуцията използва резултата, без да притежава нищо.
WSL2 е обратното. Той стартира истинско ядро в лека помощна VM зад виртуален комутатор Hyper-V и адресното му пространство се NAT-ва през адаптер от страната на хоста. Затова Linux клиент вътре в дистрибуцията се държи като на физическа Linux машина: създава tun0 или wg0, инсталира свои маршрути и работи. Отказът живее от страната на хоста. Когато Windows VPN клиент се свърже с политика, която блокира трафика в локалните мрежи, той третира подмрежата на WSL2 като недоверена локална мрежа и прекъсва пътя на NAT. Тогава дистрибуцията губи DNS и изходящ достъп, докато собственият ѝ тунел е още здрав: wg show съобщава за ръкостискане, ip route изглежда правилно, а curl виси.
Кое поправка можете да използвате зависи от изданието на Windows. По-старото е изключение в клиента на хоста за подмрежата на WSL, добавено в настройките за локална мрежа или разделен тунел на клиента. По-новото, при издания на Windows 11, които го поддържат, е огледално свързване: поставете networkingMode=mirrored в секцията [wsl2] на %UserProfile%\.wslconfig, изпълнете wsl --shutdown и дистрибуцията ще дели интерфейсите на хоста вместо частна NAT подмрежа. Огледалният режим променя и поведението на localhost и входящите портове, затова го третирайте като миграция, а не като превключвател.
NAT, мост и какво вижда хостът
Под NAT пакетите на тунела на госта се адресират към публичния адрес на VPN сървъра и излизат през адаптера на хоста като шифрован UDP или TCP. Хостът вижда един поток и броя на байтовете му, нищо за дестинациите вътре в него. Под мостов адаптер гостът има собствена идентичност на ниво 2 във физическата LAN, взема собствен DHCP наем и изглежда за всяка политика, базирана на MAC, като второ устройство. Нито един режим не позволява на хоста да чете полезния товар на тунела; мостовият гост е просто много по-видим за мрежата около него.
Има и долна граница на изолацията. Гостът не може да се скрие от машината, която притежава паметта му, и който контролира хоста, може да чете ключове от RAM паметта на госта. Тунелът в госта ви дава граница за маршрутизиране и граница за зловреден софтуер, а не защита от човека, който държи лаптопа. Документираните режими на адаптера си заслужава да са отворени, докато избирате, защото режимът променя и какво вижда хостът, и какво вижда LAN.
Наръчник: разположете, настройте, докажете
Изпълнете тези четири проверки по ред в нов шел на госта и спрете на първата, която не е в съгласие със записания собственик.
ip route get 1.1.1.1, който връщаtun0илиwg0, означава собственост на госта, аeth0с частен следващ хоп означава собственост на хоста.resolvectl query example.comили прочетете/etc/resolv.confтам, където гостът не пуска услуга за резолвер. Тунел, който носи трафик, но не и DNS, е най-честото недовършено състояние.- Сравнете изходите:
curl -4 -s https://ifconfig.meв госта срещуcurl.exe -4 -s https://ifconfig.meна хоста. Различните адреси означават, че гостът притежава тунела, а хост във VPN с гост, който показва домашния доставчик, е случаят „нищо не е наследено“. - Повторете и двете с
-6. Тунел само за v4 изтича v6, освен ако клиентът не го блокира или маршрутизира, а много клиенти оставят v6 на физическия интерфейс по подразбиране.
За схема с хост-шлюз, при която няколко госта делят един тунел, хостът трябва да препраща и транслатира. На Linux хост това са три части и гостът тихо се връща към обичайния си маршрут, когато липсва някоя от тях:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTОт страната на WireGuard AllowedIPs на хоста-партньор трябва да включва подмрежата на гостовете, например 192.168.122.0/24, иначе пакетите за връщане никога не пристигат и настройката изглежда като проблем със защитна стена. Windows хост постига същия резултат с Internet Connection Sharing или правило за NAT на комутатора Hyper-V и се нуждае от същата проверка на обратния път.
Когато оформлението е още отворено, тази таблица покрива най-честите подредби:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
Два тунела, два госта и конфликтите между тях
Когато ви трябват два изхода едновременно, моделът, който издържа, е един тунел на гост. Всяка VM пази собствения си маршрут по подразбиране и резолвер, хостът остава в обикновената мрежа и двата тунела никога не спорят за една и съща таблица за маршрутизиране. Свързването на два госта в мост също не обединява маршрутите им: виртуалната мрежа дава път и на всеки клиент все още трябва да се каже, че този локален трафик може да заобиколи тунела.
Пускането на тунел на хоста и тунел на госта заедно е законно и умишленото влагане понякога е точно това, което искате, при което гостът излиза през своя тунел, а този тунел излиза през този на хоста. Това, което го превръща в прекъсване, е че никой не е записал коя крайна точка през кой слой трябва да се достигне. Пазете списък на две колони с дестинация и собственик и конфликтът на маршрути става справка вместо следобед откривателство.
Проверете, после оставете възстановяването при собственика
Тествайте отвътре в госта с нов процес на приложението: трафик, разрешаване на имена, двете семейства адреси и какво се случва при отпадане на тунела. Иконата за VPN на хоста не казва нищо за покритието на госта и това е най-честото фалшиво потвърждение в цялата тази област.
Възстановяването също принадлежи на собственика. Тунел на госта се възстановява от собствения клиент на госта и маршрутите, които той е записал. Схема със собственик хоста се възстановява от последователността за зареждане на хоста и правилата за препращане не оцеляват при рестарт, освен ако unit или задача при стартиране не ги приложи отново. Възстановен snapshot е внедряване, а не отмяна, защото връща стари идентификационни данни и стари маршрути заедно с диска. Преди да обявите работата за свършена, потвърдете, че собственикът още съответства на реда, който записахте, че DNS и двете семейства адреси се разрешават вътре в госта, че мъртъв тунел оставя използваема мрежа вместо черна дупка и че рестарт или възстановяване от snapshot възпроизвежда същото състояние.