Kāpēc jūsu viesa VPN neizdodas aiz VirtualBox NAT?

Pārlūks virtuālajā mašīnā strādā, bet VPN klients tajā pašā viesī nevar pārnest datus. Viesim acīmredzami ir savienojamība, tāpēc kļūme ir tajā, ko prasa VPN ārējais protokols un ko virtuālais NAT laidīs cauri. Rezultātu nosaka trīs nosacījumi: kurš process pārvalda VPN, kā ārējā apmaiņa izskatās uz vada un vai adaptera režīms ir tas, ko domājat. Nosaukt nosacījumu, ko varat mainīt, ir viss lēmums.

Atrodiet VPN procesu pirms tīkla vainošanas

Vispirms izlemiet, vai VPN darbojas viesa iekšienē vai saimniekā, jo abi izkārtojumi sabojājas atšķirīgi. Klients viesa iekšienē veido savu ārējo savienojumu caur viesa adapteri un jebkuru tulkojumu aiz tā. Saimnieka VPN uztver viesa datu plūsmu saskaņā ar saimnieka un hipervizora politiku, kas ir atsevišķs uztveršanas punkts ar saviem noteikumiem. Tie var darboties vienlaikus un sajaukt pierādījumus, tāpēc pirms jebkura no tiem aizskaršanas nosakiet, kuram šī plūsma jāpārnes.

Pierakstiet viesa adaptera režīmu tagad, pirms kaut ko maināt. Šī vienīgā vērtība izskaidro lielāko daļu no tā, kas sekos, un tā ir pirmā lieta, ko vēlāk kāds jums pajautās.

Ārējā apmaiņa nosaka saderību

VirtualBox tīkla rokasgrāmata uzskaita NAT ierobežojumus, kas šeit ir svarīgi: tas nelaidīs cauri citus protokolus kā TCP un UDP, GRE ir nosaukts kā neatbalstīts, un PPTP ir dots kā skarts piemērs. PPTP izmanto TCP vadības apmaiņu un GRE datiem, tāpēc vadības savienojums var izdoties, kamēr datu ceļš nevar šķērsot to pašu robežu. Tie ir divi dažādi pierādījumi, un tikai viens no tiem ir par plūsmas pārnēsāšanu. Atļaut TCP portu 47 ugunsmūra noteikumā nav tas pats, kas atļaut IP protokolu 47, un šie divi tiek pastāvīgi sajaukti.

Turiet ierobežojumu piesaistītu šim NAT izkārtojumam, nevis katrai ierīcei, kas lieto vārdu NAT. Fizisks maršrutētājs var bez iebildumiem laist cauri GRE, kamēr virtuālais NAT to nomet, un cits hipervizors pats izvēlas, ko pārsūtīt. Kur organizācija piedāvā apstiprinātu transportu TCP vai UDP ietvaros, izmantojiet tās atbalstīto klientu un profilu šim ceļam. Saderība ir viena prasība starp vairākām, un tā neizveido ne servera uzticēšanos, ne konta atļauju, ne strādājošus privātus maršrutus.

Ko tilts patiešām maina

Tilts nodod viesa MAC adresi fiziskajam segmentam, nevis slēpj to aiz tulkojuma. Tad viesis iegūst adresi no jebkura DHCP servera, kas apkalpo šo segmentu, atbild ar ARP uz šo adresi un augšupējam komutatoram parādās kā vēl viens ports. Tas noņem virtuālā tulkojuma ceļu, un tieši tāpēc veca recepte to iesaka, un tas pašā mirklī maina vēl trīs lietas. Adresēšana tagad nāk no vietējā segmenta, nevis no hipervizora, atklāšana nozīmē, ka viesis ir redzams šim segmentam, un uzņemšana ir atkarīga no komutatora porta un tā politikas. Katrs no tiem var būt iemesls atteikt izmaiņas, un neviens no tiem nav par VPN protokolu.

Tiltošana neinstalē trūkstošu spraudni, nenodrošina nepieejamu slepenu aģentu un nelabo autentifikācijas atteikumu. Tā arī nepadara novecojušu protokolu par labu izvēli, un kur operatoram ir uzturēts aizvietotājs, lēmums ir tieši tas, nevis hipervizora maiņa. Porta pāradresācija ir pilnīgi trešā loma: tā publicē ienākošu pakalpojumu un neko nedara izejoša klienta ārējam protokolam.

Divi tuneļi, divas pierādījumu pēdas

Viesa VPN nepieciešams lietojams ceļš no viesa saskarnes līdz tā partnerim, pirms jebkura iekšējā adrese vai privāts maršruts kļūst svarīgs. Kur ir saimnieka VPN, tas var pārsūtīt vai bloķēt šo ārējo apmaiņu saskaņā ar savu politiku, un viesa iekšējais tunelis sākas tikai pēc tam, kad ārējais izdodas. Neviena slāņa pārklājumu nevar nolasīt no vienas pievienotas ikonas vai saimnieka pārlūka publiskās adreses.

Saglabājiet pirmo kļūdas ziņojumu, nevis pēdējo, jo agrākā kļūme nosauc slāni. Mainiet vienu atbalstītu tīkla izkārtojumu vienlaikus, ar to pašu viesa profilu un tiem pašiem akreditācijas datiem, lai salīdzinājumam būtu jēga. Pēc kļūmes izlemiet, kurš posms salūza: vietējā integrācija, transports, autentifikācija vai resursu piekļuve pēc tuneļa pacelšanas. Katram no tiem ir cits īpašnieks, un tikai viens ir hipervizora jautājums.

Kurš nosacījums jūs patiešām bloķē

Tagad lēmums sašaurinās līdz trim jautājumiem ar atšķirīgām atbildēm. Ja ārējais protokols atrodas ārpus TCP un UDP, NAT režīms ir ierobežojums, un ceļš uz priekšu ir tilts vai apstiprināts TCP/UDP transports. Ja ārējā apmaiņa beidzas, bet datu ceļš ne, ierobežojums ir tas pats, kas redzams otrajā pierādījumā. Ja tunelis paceļas, bet resursi neatbild, problēma jau ir pārsniegusi hipervizoru maršrutēšanā vai politikā.

Pierakstiet atbildi ar adaptera režīmu blakus, citādi nākamais cilvēks atkārtos to pašu pēcpusdienu. Pēc jebkura labojuma pārbaudiet īsto lietojumprogrammu un vārdu atrisināšanu viesa iekšienē, tad atkārtoti pievienojieties un pārbaudiet kļūmes politiku. Strādājoša tīmekļa lapa caur tuneli pierāda tikai to, ka tīmekļa ceļš strādā, un tas ir mazāks apgalvojums, nekā šķiet tajā brīdī.