Wêrom mislearret jo gast-VPN efter VirtualBox NAT?

In browser binnen de firtuele masine wurket, en de VPN-klant op deselde gast kin gjin gegevens drage. De gast hat fansels konnektiviteit, dus de flater sit yn wat it bûtenste protokol fan 'e VPN nedich hat en wat de firtuele NAT trochlitte sil. Trije betingsten beslisse de útkomst: hokker proses de VPN besit, hoe't de bûtenste útwikseling op 'e tried der útsjocht en oft de adaptermodus dejinge is dy't jo tinke. De betingst beneame dy't jo feroarje kinne is de hiele beslissing.

Lokalisearje it VPN-proses foardat jo it netwurk beskuldigje

Beslis earst oft de VPN yn 'e gast of op 'e host rint, om't de twa regelingen oars mislearje. In klant yn 'e gast bout syn eigen bûtenste ferbining fia de gastadapter en hokker oersetting dan ek dêrefter. In host-VPN fangt it ferkear fan 'e gast neffens host- en hypervisorbelied, wat in apart fangpunt mei eigen regels is. Se kinne tagelyk rinne en it bewiis betize, dus identifisearje dejinge dy't dit ferkear drage moat foardat jo ien fan beiden oanreitsje.

Skriuw de adaptermodus fan 'e gast no op, foardat jo wat feroarje. Dy iene wearde ferklearret it measte fan wat folget, en it is it earste ding dat immen jo letter freegje sil.

De bûtenste útwikseling beslút de kompatibiliteit

De VirtualBox-netwurkgids neamt NAT-beheiningen dy't hjir ta sake dogge: it sil gjin oare protokollen as TCP en UDP trochlitte, GRE wurdt neamd as net stipe, en PPTP wurdt jûn as in troffen foarbyld. PPTP brûkt in TCP-kontrôle-útwikseling en GRE foar de gegevens, dus de kontrôleferbining kin slagje wylst it gegevenpaad deselde grins net oerstekke kin. Dat binne twa ferskillende stikken bewiis, en mar ien giet oer it drage fan ferkear. TCP-poarte 47 tastean yn in firewallregel is net itselde as IP-protokol 47 tastean, en de twa wurde hieltyd betize.

Hâld de beheining fêst oan dizze NAT-regeling ynstee fan oan elk apparaat dat it wurd NAT brûkt. In fysike router kin GRE sûnder klacht trochlitte wylst de firtuele NAT it weilitten, en in oare hypervisor makket syn eigen kar oer wat er trochstjoert. Wêr't de organisaasje in goedkarde ferfier binnen TCP of UDP biedt, brûk dan syn stipe klant en profyl foar dat paad. Kompatibiliteit is ien eask ûnder ferskate, en it fêstiget noch fertrouwen yn 'e tsjinner noch tastimming fan it akkount noch wurkjende priveerûtes.

Wat bridging echt feroaret

In brêge jout it MAC-adres fan 'e gast oan it fysike segmint ynstee fan it efter oersetting te ferbergjen. De gast nimt dan in adres fan hokker DHCP-tsjinner dan ek dy't dat segmint betsjinnet, antwurdet ARP foar dat adres, en ferskynt foar de upstream-switch as noch in poarte. Dat fuortet it firtuele oersettingspaad fuort, wat krekt de reden is dat in âld resept it oanriedt, en it feroaret tagelyk trije oare dingen. Adressearring komt no fan it lokale segmint ynstee fan de hypervisor, bleatstelling betsjut dat de gast sichtber is foar dat segmint, en talitting hinget ôf fan 'e switchpoarte en syn belied. Elk dêrfan kin in reden wêze om de feroaring te wegerjen, en net ien giet oer it VPN-protokol.

Bridging ynstallearret gjin ûntbrekkende plugin, leveret gjin net-beskikbere geheime agent en reparearret in autentikaasje-ôfwizing net. It makket ek gjin ferâldere protokol in goede kar, en wêr't de operator in ûnderhâlden ferfanging hat, is dat de beslissing ynstee fan it feroarjen fan 'e hypervisor. Poartetrochstjoering is hielendal in tredde rol: it publisearret in ynkommende tsjinst en docht neat foar it bûtenste protokol fan in útgeande klant.

Twa tunnels, twa bewiispoaren

In gast-VPN hat in brûkber paad fan 'e gastynterface nei syn partner nedich foardat hokker ynterne adres of priveerûte dan ek ta sake docht. Wêr't in host-VPN oanwêzich is, kin it dy bûtenste útwikseling ûnder syn eigen belied trochstjoere of blokkearje, en de ynterne tunnel fan 'e gast begjint pas nei't de bûtenste slagge is. De dekking fan gjin in lage is te lêzen fan ien ferbûn ikoan of fan it iepenbiere adres fan 'e hostbrowser.

Hâld it earste flaterberjocht ynstee fan it lêste, om't de ierste flater de lage neamt. Feroarje ien stipe netwurkregeling tagelyk, mei itselde gastprofyl en deselde ynloggegevens, sadat de ferliking wat betsjut. Beslis út 'e flater hokker etappe brutsen is: lokale yntegraasje, ferfier, autentikaasje of tagong ta boarnen neidat de tunnel omheech is. Elk dêrfan hat in oare eigner, en mar ien is in hypervisor-fraach.

Hokker betingst blokketearret jo eins

No ferhellet de beslissing ta trije fragen mei ferskillende antwurden. As it bûtenste protokol bûten TCP en UDP sit, is de NAT-modus de beheining, en bridging of in goedkard TCP/UDP-ferfier is it paad foarút. As de bûtenste útwikseling foltôget en it gegevenpaad net, is de beheining deselde as sjoen by it twadde bewiis. As de tunnel omheech komt en boarnen net antwurdzje, is it probleem al foarby de hypervisor nei routing of belied.

Skriuw it antwurd op mei de adaptermodus derneist, oars werhellet de folgjende persoan deselde middei. Test de wiere tapassing en namme-oplossing yn 'e gast nei elke korreksje, ferbyn dan opnij en probearje it flaterbelied. In wurkjende webside troch de tunnel bewiist allinnich dat it webpaad wurket, wat in lytsere bewearing is as it op dat stuit fielt.