Kiel direkti unu retejon ekster vian WireGuard-tunelon

Eligi hostnomon estas io, kion tunelo ne povas fari. Itinero tamen povas direkti unu solan adreson preter la tunelo kaj eksteren tra la hejma pordego, kaj tio kutime sufiĉas por unu retejo. La malfacilaĵo estas, ke ĉio malsupren de la itinero devas konsenti: la fajroŝirmilo devas lasi la paketon eliri, DNS devas redoni la adreson, kiun vi direktis, kaj la retejo devas daŭre uzi tiun adreson. Kiam ajn unu el la tri drivas, la escepto ĉesas funkcii sen anonci sin.

Legi la celadreson antaŭ ol tuŝi la tunelon

Ŝargu la retejon unufoje kun la tunelo aktiva, poste rigardu la samtavolan adreson, al kiu la retumilo efektive konektiĝis. En Linukso, ss -tunp listigas la foran adreson por ĉiu malfermita konektilo, kaj dig +short pri la sama nomo montras, kion redonis la solvilo. Tenu ambaŭ numerojn antaŭ vi.

La du respondoj ofte malkongruas, kaj tiu malkongruo estas la tuta problemo. Grandaj retejoj metas enhavreton antaŭ sian originon, do la adreso, kiun via solvilo redonas nun, eble ne estas tiu, kiun la retumilo uzis antaŭ unu minuto. Direktu tion, kion vi observis ĉe la konektilo, ne tion, kion listigas pli malnova gvidilo. Se la respondoj daŭre rotacias inter regionoj, adresa escepto estas la malĝusta ilo por tiu konkreta retejo.

Rulu la serĉadon duan fojon el alia reto kaj notu la IPv6-respondon kune kun la IPv4-respondo. Tunelo, kiu portas ambaŭ familiojn, bezonas escepton en ambaŭ, alie la retumilo silentas reen al la IPv6-vojo, kiun vi neniam tuŝis. Skribu la adresojn kaj la daton ie, kie vi rigardos denove.

Meti unu hostan itinieron sur la klienton

Supozu, ke la interfaco nomiĝas home-wg kaj ke la LAN-itinero staras ĉe 192.168.1.1. NetworkManager prenas itinieron, kies pordego estas tiu itinero kaj kies prefiksa longo kovras la plenajn 32 bitojn, kaj la kerno preferas ĝin, ĉar la plej longa prefikso gajnas.

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

La pordego devas esti atingebla sen la tunelo; direkti la sekvan salton al la tunela adreso fuŝas la celon, ĉar la paketo reenirus en la interfacon, kiun vi provas eviti. Post kiam la konekto releviĝas, ip route get por la escepto devus presi la LAN-pordegon, kaj la sama komando por publika solvilo ankoraŭ devus presi la tunelan aparaton.

Profilo de wg-quick ne havas kampon por itineroj, do la sama escepto loĝas en linio PostUp kiu aldonas la hostan itinieron al la ĉefa tabelo kun la LAN-interfaco kiel sia aparato. Mallevu kaj relevu la interfacon post redaktado, ĉar funkcianta interfaco neniam relegas sian dosieron. La fwmark-reguloj, kiujn wg-quick instalas, stiras nur siajn proprajn enkapsuligitajn paketojn, do ordinara retumila trafiko plu sekvas la ĉefan tabelon kaj trovas vian /32.

La mortigŝaltilo estas la sekva afero, kiu blokas ĝin

Fajroŝirmila politiko, kiu allasas trafikon nur sur la tunela interfaco, forĵetos la escepton eĉ kiam la itinero estas tute ĝusta. Legu la regulojn malantaŭ la ŝaltilo anstataŭ fidi la ŝaltilon, ĉar tiuj, kiuj realigas mortigŝaltilon, kutime limiĝas al interfaca nomo.

Tio, kion vi volas, estas mallarĝa permeso por la fizika interfaco kaj tiu unu celo, metita antaŭ la forĵeto, dum la defaŭlta politiko restas netuŝita. Paŭzigi la mortigŝaltilon tute pruvas la punkton, sed ankaŭ lasas la maŝinon elmetita tiel longe, kiel vi forgesos reŝalti ĝin.

Testu la du direktojn aparte. Peto al la escepta adreso devus sukcesi, dum peto al nerilata retejo ankoraŭ eliras tra la tunelo. Se ambaŭ sukcesas sed la dua raportas la hejman adreson, la ordo de la fajroŝirmilaj reguloj malĝustas, ne la itinero.

DNS decidas, al kiu adreso la retumilo turniĝas

Kiam la nomo solviĝas ene de la tunelo, la solvilo de la provizanto povas respondi per alia adreso ol la loka. Via itinero tiam aplikiĝas al adreso, kiun la retumilo neniam kontaktas, kaj la paĝo ŝargiĝas tra la tunelo kvazaŭ nenio ŝanĝiĝis. Tiu fiasko aspektas kiel rompita escepto, eĉ kiam la itinera tabelo estas ĝusta.

Sendu la demandojn de tiu nomo ankaŭ tra la loka solvilo, aŭ tute preterpasu nomojn kaj testu la adreson rekte. Dividi la adreson dum DNS restas ene de la tunelo estas la plej ofta duonfinita versio de tiu agordo, kaj ĝi ankaŭ estas la plej malfacile rimarkebla, ĉar la retejo plu funkcias, nur ne tiel, kiel vi intencis.

La sama escepto sur la itinero, unufoje, por ĉiu aparato

Kiam la tunelo funkcias sur la itinero, la hosta itinero apartenas al la politika itinera tabelo de la itinero kaj montras al la WAN-pordego anstataŭ al la LAN-pordego. Ĉiu aparato malantaŭ ĝi heredas la escepton, kio gravas por elsenda skatolo aŭ labora tekkomputilo, kies retajn agordojn vi ne povas ŝanĝi.

Lasu la tunelon kiel la defaŭltan eliron por ĉiu alia kliento, poste kontrolu el klienta maŝino anstataŭ el la itinera konzolo. Ŝargu la esceptan retejon kaj duan retejon en la sama retumila sesio kaj komparu la elirajn adresojn; se la dua ankoraŭ montras la tunelon, la politika tabelo faras tion, kion vi petis.

Notu la adreson, la daton kaj la kialon en la notoj de la itinero. Escepto konstruita ĉirkaŭ adreso, kiu poste moviĝas, fariĝas difekto, kiun neniu povas klarigi post jaro, kaj la riparo ĉiam aspektas kiel mistero, ĝis iu trovas la malnovan noton.