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

Прелистувачот во виртуелната машина работи, а 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 транспорт. Ако надворешната размена заврши, а патеката на податоците не, ограничувањето е истото видено во вториот доказ. Ако тунелот се подигне, а ресурсите не одговараат, проблемот веќе го поминал хипервизорот во рутирање или политика.

Запишете го одговорот со режимот на адаптерот до него, инаку следниот човек ќе го повтори истото попладне. По секое поправање тестирајте ја вистинската апликација и решавањето имиња внатре во гостинот, потоа повторете поврзување и испробајте ја политиката при дефект. Работна веб-страница низ тунелот докажува само дека веб-патеката работи, што е помало тврдење отколку што изгледа во тој момент.