Waarom misluk jou gas-VPN agter VirtualBox NAT?

'n Blaaier binne die virtuele masjien werk, en die VPN-kliënt op dieselfde gas kan nie data dra nie. Die gas het duidelik konnektiwiteit, so die fout sit in wat die VPN se buitenste protokol nodig het en wat die virtuele NAT sal deurlaat. Drie voorwaardes bepaal die uitkoms: watter proses die VPN besit, hoe die buitenste uitruiling op die draad lyk, en of die adaptormodus die een is wat jy dink. Om die voorwaarde te benoem wat jy kan verander, is die hele besluit.

Lokaliseer die VPN-proses voordat jy die netwerk blameer

Besluit eers of die VPN binne die gas of op die gasheer loop, want die twee reëlings misluk verskillend. 'n Kliënt binne die gas bou sy eie buitenste verbinding deur die gasadapter en enige vertaling wat daaragter sit. 'n Gasheer-VPN vang die gas se verkeer op volgens gasheer- en hipervisorbeleid, wat 'n aparte vangpunt met sy eie reëls is. Hulle kan gelyktydig loop en die bewyse verwar, so identifiseer die een wat veronderstel is om hierdie verkeer te dra voordat jy enigeen aanraak.

Skryf die adaptormodus van die gas nou neer, voordat jy enigiets verander. Daardie enkele waarde verduidelik die meeste van wat volg, en dit is die eerste ding wat iemand later vir jou sal vra.

Die buitenste uitruiling bepaal versoenbaarheid

Die VirtualBox-netwerkhandleiding lys NAT-beperkings wat hier saak maak: dit sal nie protokolle anders as TCP en UDP deurlaat nie, GRE word as onondersteun genoem, en PPTP word as 'n geaffekteerde voorbeeld gegee. PPTP gebruik 'n TCP-beheeruitruiling en GRE vir die data, so die beheerverbinding kan slaag terwyl die datapad nie dieselfde grens kan oorsteek nie. Dit is twee verskillende stukke bewyse, en net een daarvan gaan oor die dra van verkeer. Om TCP-poort 47 in 'n firewallreël toe te laat is nie dieselfde as om IP-protokol 47 toe te laat nie, en die twee word gedurig verwar.

Hou die beperking vas aan hierdie NAT-reëling eerder as aan elke toestel wat die woord NAT gebruik. 'n Fisiese router kan GRE sonder klag deurlaat terwyl die virtuele NAT dit laat val, en 'n ander hipervisor maak sy eie keuse oor wat hy aanstuur. Waar die organisasie 'n goedgekeurde vervoer binne TCP of UDP bied, gebruik sy ondersteunde kliënt en profiel vir daardie pad. Versoenbaarheid is een vereiste onder verskeie, en dit vestig nie bedienervertroue of rekeningtoestemming of werkende private roetes nie.

Wat brugging werklik verander

'n Brug gee die gas se MAC-adres aan die fisiese segment eerder as om dit agter vertaling weg te steek. Die gas neem dan 'n adres van watter DHCP-bediener ook al daardie segment bedien, antwoord ARP vir daardie adres, en verskyn vir die opstroom-skakelaar as nog een poort. Dit verwyder die virtuele vertaalpad, wat juis is waarom 'n ou resep dit aanbeveel, en dit verander terselfdertyd drie ander dinge. Adressering kom nou van die plaaslike segment eerder as van die hipervisor, blootstelling beteken die gas is sigbaar vir daardie segment, en toelating hang van die skakelaarpoort en sy beleid af. Elkeen daarvan kan 'n rede wees om die verandering te weier, en nie een daarvan gaan oor die VPN-protokol nie.

Brugging installeer nie 'n ontbrekende inprop nie, verskaf nie 'n onbeskikbare geheime agent nie, of herstel nie 'n verwerping van verifikasie nie. Dit maak ook nie 'n verouderde protokol 'n goeie keuse nie, en waar die operateur 'n onderhoude plaasvervanger het, is dit die besluit eerder as om die hipervisor te verander. 'n Poortaanstuur is heeltemal 'n derde rol: dit publiseer 'n inkomende diens en doen niks vir 'n uitgaande kliënt se buitenste protokol nie.

Twee tonnels, twee bewijsspore

'n Gas-VPN het 'n bruikbare pad van die gas se koppelvlak na sy eweknie nodig voordat enige innerlike adres of private roete saak maak. Waar 'n gasheer-VPN teenwoordig is, kan dit daardie buitenste uitruiling onder sy eie beleid deurstuur of blokkeer, en die gas se innerlike tonnel begin eers nadat die buitenste een slaag. Nie een laag se dekking kan uit 'n enkele gekoppelde ikoon of uit die gasheer se blaaier se publieke adres gelees word nie.

Hou die eerste foutboodskap eerder as die laaste een, want die vroegste fout noem die laag. Verander een ondersteunde netwerkreëling op 'n slag, met dieselfde gasprofiel en dieselfde geloofsbriewe, sodat die vergelyking iets beteken. Besluit uit die fout watter stadium gebreek het: plaaslike integrasie, vervoer, verifikasie, of hulpbrontoegang nadat die tonnel op is. Elkeen van daardie het 'n ander eienaar, en net een van hulle is 'n hipervisorvraag.

Watter voorwaarde keer jou werklik

Teen hierdie tyd vernou die besluit tot drie vrae met verskillende antwoorde. As die buitenste protokol buite TCP en UDP sit, is die NAT-modus die beperking, en brugging of 'n goedgekeurde TCP/UDP-vervoer is die pad vorentoe. As die buitenste uitruiling voltooi en die datapad nie, is die beperking dieselfde een wat by die tweede stuk bewyse gesien is. As die tonnel opkom en hulpbronne nie antwoord nie, het die probleem al verby die hipervisor beweeg na roetering of beleid.

Skryf die antwoord neer met die adaptormodus daarlangs, of die volgende persoon herhaal dieselfde middag. Toets die werklike toepassing en naamresolusie binne die gas ná enige regstelling, en herverbind dan en oefen die foutbeleid. 'n Werkende webblad deur die tonnel bewys net dat die webpad werk, wat 'n kleiner bewering is as wat dit op die oomblik voel.