Чаму 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. Калі знешні абмен завяршаецца, а шлях даных не, абмежаванне тое ж, што бачна ў другім доказе. Калі тунель узнімаецца, а рэсурсы не адказваюць, праблема ўжо перайшла за гіпервізар у маршрутызацыю або палітыку.

Запішыце адказ разам з рэжымам адаптара, інакш наступны чалавек паўторыць той жа дзень. Пасля любога выпраўлення праверце ўнутры гасця рэальную праграму і развязанне імён, затым перападключыцеся і пратэстуйце палітыку збою. Працоўная вэб-старонка праз тунель даказвае толькі тое, што вэб-шлях працуе, а гэта меншае сцвярджэнне, чым здаецца ў той момант.