VPN на хостот или внатре во VM? Прирачник за одлука
Сопственикот на тунелот одлучува што што покрива. Изберете поставеност на хостот или кај гостинот, потоа потврдете ја со проверки на рутата, 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 хост го постигнува истиот резултат со Споделување интернет врска или 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 на хостот не кажува ништо за покриеноста на гостинот, и тоа е најчестата лажна потврда во целото ова поле.
Враќањето исто така му припаѓа на сопственикот. Тунелот во сопственост на гостинот се враќа со сопствениот клиент на гостинот и рутите што ги запишал. Дизајнот во сопственост на хостот се враќа со низата за подигање на хостот, а правилата за пренесување не преживуваат рестарт ако некоја единица или задача за стартување не ги примени повторно. Вратената слика е распоредување, не отповикување, зашто враќа стари уверенија и стари рути заедно со дискот. Пред да ја прогласите работата за завршена, потврдете дека сопственикот сѐ уште одговара на редот што сте го запишале, дека DNS и двете фамилии адреси се решаваат внатре во гостинот, дека мртов тунел остава употреблива мрежа наместо црна дупка, и дека рестарт или враќање на слика го репродуцира истото состојба.