Kial via gasto-VPN malsukcesas malantaŭ VirtualBox NAT?

Retumilo ene de la virtuala maŝino funkcias, kaj la VPN-kliento sur la sama gasto ne povas porti datumojn. La gasto evidente havas konektecon, do la fiasko kuŝas en tio, kion bezonas la ekstera protokolo de la VPN kaj kion la virtuala NAT trapasigos. Tri kondiĉoj decidas la rezulton: kiu procezo posedas la VPN, kiel la ekstera interŝanĝo aspektas sur la drato, kaj ĉu la adaptila reĝimo estas tiu, kiun vi pensas. Nomi la kondiĉon, kiun vi povas ŝanĝi, estas la tuta decido.

Unue trovu la VPN-procezon, antaŭ ol kulpigi la reton

Unue decidu, ĉu la VPN funkcias ene de la gasto aŭ sur la gastiganto, ĉar la du aranĝoj fiaskas malsame. Kliento ene de la gasto konstruas sian propran eksteran konekton tra la gastada adaptilo kaj ajna traduko malantaŭ ĝi. Gastiganta VPN kaptas la trafikon de la gasto laŭ la politiko de la gastiganto kaj de la hipervidigilo, kio estas aparta kaptpunkto kun propraj reguloj. Ili povas funkcii samtempe kaj konfuzi la pruvojn, do identigu la unu, kiu devas porti ĉi tiun trafikon, antaŭ ol tuŝi iun ajn.

Notu la adaptilan reĝimon de la gasto nun, antaŭ ol ŝanĝi ion ajn. Tiu ununura valoro klarigas plejparton de tio, kio sekvas, kaj ĝi estas la unua afero, pri kiu iu demandos vin poste.

La ekstera interŝanĝo decidas la kongruecon

La reta gvidilo de VirtualBox listigas NAT-limigojn, kiuj gravas ĉi tie: ĝi ne trapasigos protokolojn krom TCP kaj UDP, GRE estas nomata nesubtenata, kaj PPTP estas donata kiel tuŝita ekzemplo. PPTP uzas TCP-kontrolinterŝanĝon kaj GRE por la datumoj, do la kontrolkonekto povas sukcesi dum la datenvojo ne povas transiri la saman limon. Tiuj estas du malsamaj pruvoj, kaj nur unu el ili temas pri portado de trafiko. Permesi TCP-porton 47 en fajroŝirma regulo ne samas kiel permesi IP-protokolon 47, kaj la du estas konstante konfuzataj.

Tenu la limigon ligita al ĉi tiu NAT-aranĝo, ne al ĉiu aparato, kiu uzas la vorton NAT. Fizika enkursigilo povas trapasigi GRE sen plendo, dum la virtuala NAT faligas ĝin, kaj alia hipervidigilo faras sian propran elekton pri tio, kion ĝi plusendas. Kie la organizo proponas aprobitan transporton ene de TCP aŭ UDP, uzu ĝian subtenatan klienton kaj profilon por tiu vojo. Kongrueco estas unu postulo inter pluraj, kaj ĝi establas nek servantan fidindecon nek kontan permeson nek funkciantajn privatajn vojojn.

Kion pontado efektive ŝanĝas

Ponto transdonas la MAC-adreson de la gasto al la fizika segmento anstataŭ kaŝi ĝin malantaŭ traduko. La gasto tiam prenas adreson de iu ajn DHCP-servilo, kiu servas tiun segmenton, respondas ARP por tiu adreso, kaj aperas al la supra komutilo kiel ankoraŭ unu haveno. Tio forigas la virtualan tradukvojon, kio estas ĝuste kial malnova recepto rekomendas ĝin, kaj ĝi ŝanĝas tri aliajn aferojn sammomentan. Adresado nun venas de la loka segmento anstataŭ de la hipervidigilo, elmontro signifas, ke la gasto estas videbla al tiu segmento, kaj akcepto dependas de la komutila haveno kaj ĝia politiko. Ĉiu el tiuj povas esti kialo rifuzi la ŝanĝon, kaj neniu el ili temas pri la VPN-protokolo.

Pontado ne instalas mankan kromaĵon, ne liveras neatingeblan sekretan agenton, kaj ne riparas aŭtentikan malakcepton. Ĝi ankaŭ ne faras malmodernan protokolon bona elekto, kaj kie la funkciigisto havas prizorgatan anstataŭaĵon, tio estas la decido anstataŭ ŝanĝi la hipervidigilon. Havenplusendo estas tute tria rolo: ĝi publikigas envenantan servon kaj faras nenion por la ekstera protokolo de elira kliento.

Du tuneloj, du pruvotrakoj

Gasto-VPN bezonas uzeblan vojon de la gastada interfaco al sia kunulo antaŭ ol iu interna adreso aŭ privata vojo gravas. Kie gastiganta VPN ĉeestas, ĝi povas plusendi aŭ bloki tiun eksteran interŝanĝon laŭ sia propra politiko, kaj la interna tunelo de la gasto komenciĝas nur post kiam la ekstera sukcesas. La kovrado de neniu tavolo estas legebla de unu konektita ikono aŭ de la publika adreso de la gastiganta retumilo.

Konservu la unuan erarmesaĝon anstataŭ la lastan, ĉar la plej frua fiasko nomas la tavolon. Ŝanĝu unu subtenatan retan aranĝon samtempe, kun la sama gastoprofilo kaj la samaj akreditaĵoj, por ke la komparo signifu ion. Decidu laŭ la fiasko, kiu etapo rompiĝis: loka integriĝo, transporto, aŭtentikigo aŭ aliro al rimedoj post kiam la tunelo staras. Ĉiu el ili havas malsaman posedanton, kaj nur unu estas demando pri hipervidigilo.

Kiu kondiĉo efektive baras vin

Nun la decido mallarĝiĝas al tri demandoj kun malsamaj respondoj. Se la ekstera protokolo staras ekster TCP kaj UDP, la NAT-reĝimo estas la limigo, kaj ponto aŭ aprobita TCP/UDP-transporto estas la vojo antaŭen. Se la ekstera interŝanĝo kompletiĝas kaj la datenvojo ne, la limigo estas la sama vidata en la dua pruvo. Se la tunelo stariĝas kaj rimedoj ne respondas, la problemo jam pasis preter la hipervidigilo en enkursigon aŭ politikon.

Skribu la respondon kun la adaptila reĝimo apude, alie la sekva persono ripetos la saman posttagmezon. Testu la efektivan aplikaĵon kaj nomrezolucion ene de la gasto post ajna korekto, poste rekonektiĝu kaj provu la fiaskan politikon. Funkcianta retpaĝo tra la tunelo pruvas nur, ke la reta vojo funkcias, kio estas pli malgranda aserto ol ĝi sentiĝas en tiu momento.