Защо VPN гост не работи зад NAT на VirtualBox?

Браузърът във виртуалната машина работи, а VPN клиентът на същия гост не може да пренася данни. Гостът очевидно има свързаност, така че повредата е в това, което външният протокол на VPN изисква и което виртуалният NAT ще пропусне. Три условия решават изхода: кой процес притежава VPN, как изглежда външният обмен по мрежата и дали режимът на адаптера е този, за който мислите. Да назовете условието, което можете да промените, е цялото решение.

Открийте процеса на VPN, преди да обвинявате мрежата

Първо решете дали VPN работи вътре в госта, или на хоста, защото двете подредби се провалят по различен начин. Клиент вътре в госта изгражда своята външна връзка през адаптера на госта и каквото преобразуване стои зад него. VPN на хоста прихваща трафика на госта според политиката на хоста и хипервизора, което е отделна точка за прихващане със свои собствени правила. Те могат да работят едновременно и да объркат доказателствата, затова определете кой трябва да носи този трафик, преди да пипате който и да е от тях.

Запишете режима на адаптера на госта сега, преди да промените нещо. Тази единствена стойност обяснява голяма част от следващото и е първото, което всеки ще ви попита по-късно.

Външният обмен решава съвместимостта

Ръководството за мрежи на VirtualBox изброява ограничения на NAT, които имат значение тук: той няма да пропусне протоколи, различни от TCP и UDP, GRE е посочен като неподдържан, а PPTP е даден като засегнат пример. PPTP използва TCP за контролния обмен и GRE за данните, така че контролната връзка може да успее, докато пътят на данните не може да пресече същата граница. Това са две различни части от доказателства и само едната е за пренасяне на трафик. Разрешаването на TCP порт 47 в правило на защитна стена не е същото като разрешаване на IP протокол 47 и двете постоянно се бъркат.

Дръжте ограничението вързано към тази NAT подредба, а не към всяко устройство, което използва думата NAT. Физически рутер може да пропусне GRE без оплакване, докато виртуалният NAT го изхвърля, а различен хипервизор прави свой собствен избор какво препраща. Когато организацията предлага одобрен транспорт в TCP или UDP, използвайте поддържания му клиент и профил за този път. Съвместимостта е едно изискване сред няколко и тя не установява нито доверие към сървъра, нито разрешение на акаунта, нито работещи частни маршрути.

Какво всъщност променя мостовото свързване

Мостът предава MAC адреса на госта на физическия сегмент, вместо да го крие зад преобразуване. След това гостът получава адрес от който и да е DHCP сървър, обслужващ този сегмент, отговаря на ARP за този адрес и се появява пред горния комутатор като още един порт. Това премахва пътя на виртуалното преобразуване, което е точно причината стара рецепта да го препоръчва, и променя още три неща в същия момент. Адресирането сега идва от локалния сегмент, а не от хипервизора; излагането означава, че гостът е видим за този сегмент; а допускането зависи от порта на комутатора и неговата политика. Всяко от тези може да е причина да откажете промяната и никое от тях не е за VPN протокола.

Мостовото свързване не инсталира липсващ плъгин, не доставя недостъпен таен агент и не поправя отказ при удостоверяване. То също не прави остарял протокол добър избор и където операторът има поддържан заместител, решението е именно той, а не смяна на хипервизора. Пренасочването на порт е напълно трета роля: то публикува входяща услуга и не прави нищо за външния протокол на изходящ клиент.

Два тунела, две следи от доказателства

VPN гост се нуждае от използваем път от интерфейса на госта до неговия партньор, преди който и да е вътрешен адрес или частен маршрут да има значение. Когато има VPN на хоста, той може да препраща или блокира този външен обмен по своята политика и вътрешният тунел на госта започва само след като външният успее. Покритието на нито един слой не може да се прочете от една свързана икона или от публичния адрес на браузъра на хоста.

Пазете първото съобщение за грешка, а не последното, защото най-ранният отказ назовава слоя. Променяйте една поддържана мрежова подредба наведнъж, със същия профил на госта и същите идентификационни данни, за да означава нещо сравнението. От отказа решете кой етап се е счупил: локална интеграция, транспорт, удостоверяване или достъп до ресурси след вдигане на тунела. Всяко от тях има различен собственик и само едно е въпрос за хипервизора.

Кое условие всъщност ви блокира

Дотук решението се стеснява до три въпроса с различни отговори. Ако външният протокол е извън TCP и UDP, ограничението е режимът на NAT и пътят напред е мостово свързване или одобрен TCP/UDP транспорт. Ако външният обмен завършва, а пътят на данните не, ограничението е същото, видяно във второто доказателство. Ако тунелът се вдигне, а ресурсите не отговарят, проблемът вече е преминал отвъд хипервизора в маршрутизация или политика.

Запишете отговора с режима на адаптера до него, иначе следващият човек ще повтори същия следобед. Тествайте реалното приложение и разрешаването на имена вътре в госта след всяка корекция, после се свържете отново и изпробвайте политиката при отказ. Работеща уеб страница през тунела доказва само, че уеб пътят работи, което е по-малко твърдение, отколкото изглежда в момента.