Atingi hejman aparaton per VPN de fora aliro: kvin pordegoj

Komerca VPN por eliro al la interreto kaŝas vian adreson; ĝi ne konektas vin al via propra domo. Atingi la NAS-on aŭ la printilon en hejma reto bezonas enirejon sur tiu reto kaj klienton, kiu konstruas tunelon al ĝi. La paketo poste devas trapasi kvin kontrolojn, kaj iu ajn malsukceso aspektas same de ekstere.

Pordego 1: la kliento devas elekti la tunelon

Kontrolu, ĉu la celloko-prefikso vere enkursiĝas en la tunelon ĉe la kliento. Split-tunela profilo, kiu puŝas nur la propran subreton de la VPN, sendos 192.168.x.x rekte el la loka interfaco, kie ĝi iras nien. Rigardu la enkursigan tabelon de la kliento, ne la profilan nomon.

Tio estas la plej ofta malsukceso ĉe telefonaj klientoj, kiuj ofte defaŭlte sendas nur DNS aŭ nur unu prefikson. Se la vojo mankas, la manpremo povas esti perfekta kaj la aparato tamen neatingebla.

Konfirmu, ke la pula adreso de la kliento kaj la hejma subreto ne interkovras antaŭ ol daŭrigi.

Pordego 2: la enirejo devas plusendi

La VPN finiĝas ĉe gastiganto, kiu devas plusendi la malĉifritan paketon al la LAN. Tio postulas ŝaltitan IP-plusendadon kaj fajroŝirma politiko, kiu permesas la fluon de la VPN-interfaco al la LAN-interfaco. Sur enkursigila aparato tio kutime estas enkonstruita; sur Linuksa skatolo kun strongSwan aŭ WireGuard tio estas du agordoj, kiujn homoj forgesas. Kontrolu ambaŭ antaŭ ol testi la servon, ĉar ĉiu sola produktas la saman tempolimon.

Testu per kaptaĵo sur la LAN-interfaco, ĉar paketo, kiu neniam aperas tie, estis forĵetita aŭ neniam plusendita.

Tio estas malsama malsukceso ol servo, kiu rifuzas la konekton, kaj tiu distingo ŝparas multe da tempo. Tenu la permeson mallarĝa, limigita al la servo kaj la VPN-pulo anstataŭ la tuta subreto.

Pordego 3: la responda vojo decidas ĉion

La celo respondas al la fonta adreso, kiun ĝi vidis, kiu estas aŭ la pula adreso de la kliento aŭ la enirejo, laŭ tio, ĉu vi tradukas. Se la defaŭlta enirejo de la celo estas la hejma enkursigilo kaj tiu enkursigilo havas neniun vojon al la VPN-pulo, la respondo eliras per la interreto kaj mortas. Tio estas la klasika unudirekta konekto.

Ekzistas du legitimaj solvoj: aldoni vojon por la pulo sur la LAN-enirejo, aŭ source-NAT ĉe la VPN-enirejo, por ke la celo ĉiam vidu nur la enirejan adreson. La dua estas pli facila kaj perdas la originalan fontan identecon.

Elektu unu konscie kaj skribu, kiun, ĉar fajroŝirmaj reguloj kaj protokoloj dependas de ĝi. La plusenda gvidilo de strongSwan trairas la Linuksan flankon de tiu decido.

Pordego 4: nomoj kaj prefiksa interkovro

Lokaj malkovraj nomoj ne transiras enkursigitan limon, do aparato, kiu ene de la domo aperas kiel amika nomo, povas esti nevidebla tra la tunelo. Provizu DNS por la privata zono, aŭ dokumentu la adreson. Kiun ajn nomon vi uzas, ĝi devas solviĝi al io, kion la fora kliento povas enkursigi. Tial aparato povas esti atingebla laŭ adreso kaj nevidebla laŭ nomo samtempe.

Interkovrantaj prefiksoj estas la alia kaptilo: se la klienta pulo estas 192.168.1.0/24 kaj la hejma reto ankaŭ, la kliento traktas la celon kiel lokan kaj neniam sendas ĝin tra la tunelo.

Renumeru unu flankon, aŭ uzu pulon el gamo, kiun vi neniam renkontos hejme.

Pordego 5: testu de ekster la domo

Testo el la kuirejo pruvas nenion, ĉar la trafiko eble neniam forlasas la LAN-on. Konektu el poŝa hotspot aŭ alia reto, poste trairu la pordegojn laŭ ordo: vojo ĉe la kliento, kaptaĵo sur la LAN-interfaco, respondo de la servo, kaptaĵo de la respondo kaj nomsolvado. La unua pordego, kiu produktas neniun pruvon, estas kie la laboro estas.

Se la servo respondas sed la nomo ne, vi havas DNS-problemon anstataŭ tunelan problemon.

Konservu la funkciantan agordon en noto kun la pulo, la vojo kaj la NAT-elekto, ĉar la sekva enkursigila anstataŭigo restarigos ĉiujn tri.