Verda ikono, sama publika IP: kiun itineron la VPN preterlasis

Konektite, verda pleto-ikono, kaj paĝo de adresa eĥo ankoraŭ montras la adreson de la provizanto, tio ne aŭtomate signifas difekton. Kliento faras du apartajn taskojn: ĝi konstruas tunelon, kaj ĝi redaktas la enkursig-tabelon. Ĉiu povas okazi sen la alia, kaj selekta enkursigo estas la agordo kie la dua estas intence preterlasata.

Kion la kliento efektive instalis

Demandu, kiu interfaco portus paketon al reala celo, anstataŭ demandi, ĉu la tunelo estas aktiva. Tunelo sen itinero al tiu celo estas privata vojo, kiun neniu uzas.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

La unua komando respondas en Linux kaj macOS, kaj la aliaj du estas la Windows-ekvivalentoj, kie unu sufiĉas. Se la respondo nomas la fizikan adaptilon, la tunelo estas aktiva kaj la defaŭlta itinero neniam moviĝis. Ripetu la esploron por celo, kiu devus uzi la tunelon, ĉar du esploroj, unu malproksima kaj unu ordinara, diras al vi, kiu dezajno estas deplojita.

Tri formoj de selekta enkursigo

Plena tunela profilo kutime skribas defaŭltan itineron al la interfaco, aŭ skribas la paron de duonampleksaj prefiksoj, kiuj venkas laŭ prefiksa longo dum la origina defaŭlta restas en la tabelo. Selekta enkursigo estas la alia elekto, kaj ĝi venas en pluraj formoj. Unu profilo enkursigas unu gastiganton, ekzemple RDP-servilon, alia enkursigas publikan amplekson, kiun oni devas atingi el difinita loko, kaj tria intence ekskludas unu aplikaĵon. Ĉiuj tri estas legitimaj, kaj neniu ŝanĝas la adreson, kiun vidas ordinara retejo.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Legu la profilon por la direktivo, kiu decidas, kaj poste la tabelon por tio, kion ĝi produktis. Puŝita direktivo ankaŭ povas esti subpremata en la kliento, tial la profilo kaj la tabelo devas kongrui antaŭ ol vi kulpigos la servilon.

La kontraŭa flanko devas reskribi la fontan adreson

Estas dua paneo, kiu el la retumilo aspektas idente. La itinero iras en la tunelon, la servilo ricevas la paketojn kaj poste plusendas ilin kun netuŝita privata adreso de la kliento. La sekva salto ne havas revenan vojon por tiu adreso, do respondoj malaperas kaj paĝoj pendas. La servilo devas entute plusendi, kaj ĝi devas traduki la fonton en ion, kion la interreto povas enkursigi reen.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Nomu la interfacon, kiu efektive rigardas al la interreto, kio en moderna distribuo ne ĉiam estas eth0. Gastigita servilo kun fiksa adreso povas eksplicite traduki al tiu adreso anstataŭ uzi masquerade. Ambaŭ duonoj gravas, ĉar plusendo sen traduko likas neenkursigeblajn fontojn, dum traduko sen plusendo neniam vidas la paketon.

Nomrezolucio prenas sian propran vojon

Trafiko povas eliri tra la tunelo dum la esploro, kiu trovis la nomon, iris al solvilo en la loka reto. La videbla adreso restas la sama, la demandoj ne, kaj ĝuste tiun breĉon elektas disigita DNS-dezajno.

resolvectl status | head -20
resolvectl query example.org

Rimarku, kiu servilo respondis kaj ĉu ĝi diferencas de la bazo antaŭ la tunelo. En disigita tunelo tio kutime estas la agordo, kiun homoj volis ŝanĝi kiam ili plendis pri la adreso, kaj ĝi estas tiu, kiun ili neniam rigardis.

Kvar observoj, kiuj solvas la aferon

Registru la eliran adreson kun la tunelo malaktiva, poste aktiva. Rulu la celan esploron en ambaŭ statoj kaj notu la interfacon ĉiufoje.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Kiam la esploro eniras la tunelon kaj la eĥo ankoraŭ montras la adreson de la provizanto, mankas traduko ĉe la elirejo. Kiam la esploro surteriĝas sur la fizika adaptilo, la profilo estas selekta kaj la publika adreso neniam estis en la afero. Anstataŭigu la eĥan servon per unu, kiun vi fidas, kaj registru la kvar observojn kune, ĉar aparte ili estas anekdotoj. Kune ili identigas, kiun el la du taskoj la kliento efektive plenumis.