Gasta VPN kaj gastiga VPN: kiu vojo vere venkas

Du klientoj funkcias samtempe, ĉiu konvinkita ke ĝi posedas la implicitan vojon, kaj la simptomo aperas kiel io stranga: unu gasta aplikaĵo funkcias, alia solviĝas al la malĝusta loko. VPN ene de gasto kaj VPN sur la gastiganto povas kunekzisti, sed nur kiam la ekstera vojo kaj la interna politiko konsentas pri tio, kiu portas kion. Startigi ambaŭ ne kreas ĉenon per si mem. Unue registru la aliĝon, poste ŝanĝu unu aferon samtempe.

Unue registru la aliĝon de la gasto

La gasto atingas sian VPN-servilon per tiu vojo, kiun donis al ĝi la hipervizoro: NAT malantaŭ la gastiganto, ponto al la fizika segmento, aŭ reto nur por la gastiganto kun enkursigo aldonita supre. Ĉiu aliĝo ŝanĝas tion, kion la gasto povas vidi kaj kion la gastiganto povas fari al ĝia trafiko. Sub NAT la pakaĵoj de la gasto ŝajnas veni de la gastiganto, do la propra tunelo de la gastiganto povas porti ilin sen ke la gasto sciu ion pri tio. Sub ponto la gasto havas propran ĉeeston sur la segmento kaj propran implicitan enirejon.

Registru la aliĝon antaŭ ol tuŝi iun ajn agordon, kune kun tio, kiu kliento devas porti kiun aplikaĵon. Tiu frazo solvas plimulton de ĉi tiuj kazoj, ĉar la du klientoj kutime baziĝas sur malsamaj supozoj. Gasto, de kiu oni atendas uzi la tunelon de la gastiganto, ne rajtas ankaŭ havi propran konkurencan implicitan vojon.

Sekvu la finpunkton de la gasto eksteren

Gasta VPN bezonas uzeblan vojon al sia propra servilo antaŭ ol io ajn alia povas funkcii. Kiam la tunelo de la gastiganto estas aktiva kaj la gasto sidas malantaŭ NAT, la manpremo de la gasto eliras tra la tunelo de la gastiganto, kio estas aŭ la intenco aŭ akcidento, kiun neniu dokumentis. Kiam la tunelo de la gastiganto falas kaj la gasto dependis de ĝi, la gasto perdas konektecon sen eĉ unu ŝanĝo siaflanke. Sekvado de la finpunkto eksteren diras al vi, kiun el tiuj du vi efektive havas.

Vasta vojo en ajna el la du kuntekstoj kaptas trafikon, kiun la alia kliento atendis. Vasta 0.0.0.0/0-vojo ene de la gasto kaj gastiganta kliento kun plena tunelo ambaŭ postulas ĉion, kaj venkas tiu, kiu validas laste. Interkovroj inter la virtualaj retoj de la gasto, la loka LAN kaj malproksimaj retoj produktas la saman efikon por privataj prefiksoj, kun fiaskoj similaj al aŭtentigaj problemoj; la konduto de adres-traduko estas la sama, kiu estas priskribita por kontenera retumado.

Komparu registron antaŭ kaj post

Prenu bazlinion kun la tunelo de la gastiganto malŝaltita, aŭ en kiu ajn kontrolita stato via politiko permesas, kaj registru la vojon kaj solvilon de la gasto. Poste apliku la kombinatan agordon kaj komparu la du registrojn, konservante la privatecajn postulojn. Se rekta bazlinio ne taŭgas, skribu tiun limigon en la registron anstataŭ preterlasi la komparadon.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

La voja demando nomas la interfacon kaj fontan adreson, kiuj portus specifan celon, kaj ĝi estas la plej utila linio en ĉi tiu esploro. La listo de reguloj montras, ĉu politika enkursigo sendas iujn celojn tra dua tabelo. La eligado de la solvilo montras, ĉu DNS sekvis la tunelon de la gasto aŭ restis sur la vojo de la gastiganto. Rulu la samajn tri komandojn antaŭ kaj post la ŝanĝo, kaj la delto nomos la kaŭzanton.

Tenu posedrajton klara trans restartoj

La limigo de loka aliro de gastiganta kliento povas bloki trafikon al virtuala NAT aŭ ponto, kaj tiu limigo ofte estas konfuzata kun problemo de akreditaĵoj de la gasto. Legu la dokumentitan konduton de la kliento anstataŭ malŝalti la limigon por igi teston pasi. Post subtenata korekto, retestu la gastan aplikaĵon kaj la fiaskpolitikon, kiun vi postulas. Gastiganto, kiu sukcese rekonektiĝas, pruvas nenion pri la vojo aŭ solvilo de la gasto.

Decidu, kiu flanko posedas la implicitan vojon, kaj skribu tion en la operacian manlibron. Restarto de la gasto aŭ retŝanĝo ĉe la gastiganto, kiu silente renversas posedrajton, produktas cimraporton pri VPN, kiu neniam kulpis. La aranĝo devus postvivi restartigon sen ke iu memoru, kial ĝi funkciis.