La tunelo ekfunkcias, la retpaĝo de la hipervizoro tempolimas, kaj la kliento diras ke ĝi estas konektita. Tiu kombino ekskludas surprize multe: la VPN-manpremo funkcias, la kliento havas adreson, kaj la finpunkto estas atingebla. Restas mallonga listo de demandoj pri itinado kaj politiko, kaj ili havas naturan ordon. Trakuru ilin de la hipervizoro eksteren anstataŭ de la kliento enen, ĉar la propra stato de la hipervizoro estas la plej malmultekosta afero konfirmi.

Komencu per la administra segmento

Konfirmu la administran adreson de la hipervizoro kaj la servon aŭskultantan sur ĝi, kaj konfirmu ke la paĝo ŝargiĝas de alia gastiganto en tiu segmento antaŭ ol diagnozi ion ajn malproksime. Loka testado kiu malsukcesas ne estas VPN-problemo, kaj ĝi estas kvinminuta kontrolo kiu ŝparas horon.

Poste la du vojoj. La VPN-kliento bezonas itineron al la administra reto, kio kutime signifas ke AllowedIPs de la kliento aŭ puŝitaj itineroj inkluzivas tiun subreton. La hipervizoro, aŭ ĝia implicita pordego, bezonas revenan vojon al la klienta adresa baseno, krom se la dezajno intence tradukas la fonton ĉe la eniro. Tiuj estas du apartaj faktoj kaj manko de iu ajn el ili produktas la saman tempolimon. Kontrolu ilin aparte: ip route get 192.168.10.20 ĉe la kliento, kaj kaptaĵo ĉe la hipervizora gastiganto montranta ĉu la paketo alvenis entute.

Permesu la realan malproksiman administranton

Rajtigo estas aparta demando de atingeblo. Uzu pordegan kaj gastigan politikon limigitan al la fontoj kaj servoj bezonantaj administran aliron. Gastiga VPN-konto bezonanta unu laboratorian aplikaĵon ne devus per tio atingi la administran ebenon, kaj plata regulo akceptanta la tutan tunelan subreton estas kiel tio okazas.

Tenu ŝaltitaj la propran aŭtentikigon de la hipervizoro kaj la atestilan kontroladon. Privata itinero ne estas kialo por klaki tra neatendita identeca averto.

La averto indas esti traktata kiel trovo anstataŭ kiel baro. Se la atestilo ne kongruas kun la nomo kiun vi uzis, aŭ la nomo malĝustas aŭ la servo ne estas tiu kiun vi pensas, kaj ambaŭ respondoj pli gravas ĉe administra interfaco ol ie ajn alie. Atingu la paĝon per la nomo por kiu la atestilo estis eldonita, kaj lasu DNS montri tiun nomon al la tunela adreso. Privata nomo kiu solviĝas malkonsekvence inter la LAN kaj la tunelo estas ofta kaŭzo de atestilaj plendoj kiuj aspektas kiel VPN-misoj.

Kontrolu duarangajn ligojn

Iuj funkcioj uzas ligojn kiujn la retpaĝo ne uzas. Konzola seanco, ISO-ŝuto, VNC aŭ SPICE-prokurilo kaj migrada kanalo povas ĉiu uzi malsaman pordon aŭ malsaman gastigan adreson. Kiam la paĝo ŝargiĝas kaj unu funkcio malsukcesas, legu la postulon de tiu produkto anstataŭ malfermi ĉiun pordon sur la gastiganto.

Malfermi ĉion estas kiel administra interfaco fariĝas negestionata. Ĉiu plia pordo estas alia aŭskultanto mantenenda, kaj hipervizoro jam elmontras sufiĉe da ili. Identigu la specifan ligon kiun la funkcio bezonas, konfirmu ke ĝi estas atingebla tra la tunelo, kaj lasu la reston fermita. Se la funkcio insistos pri rekta ligo al gastiga adreso kiu ne estas itinebla tra via tunelo, tio estas dezajna limigo pritraktenda intence, ne kialo plusendi gamon.

Konservu revenvojon antaŭ ol tuŝi la reton

Antaŭ ol vi ŝanĝos la virtualan reton kiu portas vian propran VPN, konfirmu ke vi havas lokan aŭ sendependan revenvojon.

Tio plej gravas en hejma laboratorio, ĉar la VPN-finpunkto ofte estas virtuala maŝino sur ĝuste tiu hipervizoro kiun vi provas atingi. Ŝanĝi virtualan ŝaltilon, ponton aŭ fajroŝirman regulon malproksime povas forigi la vojon kiun vi uzas, kaj la seanco povas postvivi sufiĉe longe por vidi tion okazi.

Testu de ekster la laboratorio anstataŭ de la LAN, kaj kontrolu la rifuzojn same kiel la permesojn. Reto kiu devus resti neatingebla de la tunelo devus resti neatingebla post via ŝanĝo, kaj tio estas aparta aserto de la ŝarĝiĝo de la administra paĝo. Skribu ambaŭ rezultojn, ĉar la dua estas tiu kiun oni preterlasas kaj tiu kiu gravas kiam la laboratorio kreskas.

La rikordo konservenda estas mallonga: la administra adreso kaj servo, la itinero kiun ĉiu flanko bezonas, la identecoj rajtigitaj atingi ĝin, kaj la reakira vojo. Tio sufiĉas por ke la sekva persono reproduktu la funkciantan staton sen rederivi ĝin.

Se la paĝo ankoraŭ tempolimas post ĉio tio, kaptu ĉe la hipervizoro kaj serĉu la paketon antaŭ ol ŝanĝi alian regulon. Paketo kiu neniam alvenas estas demando pri itinado aŭ fajroŝirmilo; paketo kiu alvenas kaj estas rifuzata estas demando pri servo aŭ politiko; paketo kiu alvenas kaj estas respondata dum la kliento atendas estas demando pri revena vojo. La dokumentaro de strongSwan pri plusendo klarigas kiel Linuksa pordego plusendas tunelan trafikon al interna gastiganto. Tri kaptaĵoj venkas unu plian konjekton.

Rilataj artikoloj