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

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