Plena tunelo WireGuard: AllowedIPs 0.0.0.0/0 ne sufiĉas

Meti 0.0.0.0/0, ::/0 en la AllowedIPs de kunulo estas la paŝo, kiun ĉiuj memoras, kaj ĝi nur decidas, kiun trafikon la kunulo rajtas porti. Tiuj prefiksoj kreas neniujn itineron, plusendas nenion ĉe la malproksima flanko, kaj lasas la solvilon de ĉiu aplikaĵo ĝuste tie, kie ĝi estis. Kvar apartaj aferoj devas validi samtempe, por ke plena tunelo estu plena tunelo, kaj plej bone kontroli ilin en la suba ordo, ĉar posta kontrolo ne povas savi pli fruan. Ĉiu suba kontrolo estas fakto, kiun oni povas legi de maŝino, ne agordo, kiun vi esperas esti aplikita.

Kion la kunula prefikso elektas, kaj kion ne

AllowedIPs samtempe estas elektilo kaj permesilo. Ĝi diras al la loka flanko, kiujn celojn oni rajtas sendi al ĉi tiu kunulo, kaj ĝi diras al la riceva flanko, kiujn fontajn adresojn ĉi tiu kunulo rajtas prezenti. Tio estas la tuta laboro. Nenio en tiu priskribo kreas itineron sur la gastiganto, ŝaltas plusendadon ĉe la malproksima flanko, aŭ tuŝas nomrezolucion.

Tial agordo povas aspekti kompleta kaj konduti kiel dividita tunelo. La prefikso diras, ke la kunulo akceptus ĉion; la enruta tabelo de la gastiganto decidas, kio efektive alvenas tie, kaj la enirejo decidas, ĉu io eliras. Neniu el tiuj tri decidoj loĝas en la kunula sekcio.

Enruti la klienton, ne nur la kunulan liston

Administriloj kiel wg-quick programigas la enrutan tabelon de la gastiganto por vi, kaj tial du identaj agordaj dosieroj kondutas malsame depende de tio, kiel la interfaco ekfunkciis. Minimuma profilo estas sufiĉe mallonga por legi ĝin unufoje:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Du detaloj portas la laboron. La kampo Address estas unu gastiganta prefikso anstataŭ subreto, kiun la kliento kredas posedi, kaj la administrilo estas tiu, kiu konvertas la defaŭltajn AllowedIPs en realan defaŭltan itineron. Levu la saman dosieron per ip link kaj wg setconf kaj neniuj itineraj aperos entute, kio aspektas kiel rompita tunelo kaj estas sana tunelo kun la enruta paŝo preterlasita. La manlibro de wg-quick dokumentas la enrutadon kaj la Table konduton, kiun tiuj administriloj aldonas.

Legu la rezulton anstataŭ la dosieron: ip route get 1.1.1.1 devus nomi la tunelan interfacon, kaj wg show devus raporti lastatempan manpremon kun moviĝanta transiga nombrilo. Manpremo sen itinero signifas, ke la administrilo neniam ruliĝis, kaj redakti la profilon denove tion ne riparos. Startigu la interfacon tiel, kiel la uzanto startigos ĝin, alie la testo mezuras vian ŝelon anstataŭ la deplojon.

Teni la finpunkton ekster la tunelo

Plena tunelo kaptas ĉiun celon, inkluzive tiun, kun kiu ĝi devas paroli por ekzisti. Administriloj solvas tion aldonante gastigantan itineron por la finpunkto tra la originala enirejo, kaj tial ĝusta agordo preskaŭ ĉiam enhavas unu intencan escepton. Apliki duonon de la agordo per administrilo kaj la alian duonon permane estas la kutima maniero, kiel tiu escepto perdiĝas.

Se la finpunkto estas gastiganta nomo, kiu solviĝas al pluraj adresoj, aŭ al familio, kiun vi ne portas, la escepto maljuniĝas malbone kaj la tunelo povas fiaski post rekonekto, kiu aspektis rutina. Fiksu la finpunkton al adreso, kiun vi kontrolas, aŭ konfirmu, ke la administrilo ree taksas ĝin, kaj relegu la gastigantan itineron post ĉiu reta ŝanĝo.

La sama mekanismo klarigas, kial plena tunelo kaj kapta portalo kverelas. La portalo atendas interkapti la trafikon, kiun via tunelo nun kaptas, do en hotelaj kaj flughavenaj retoj vi levu la tunelon post la portala ensaluto, neniam antaŭe.

Plusendado kaj la revena vojo ĉe la enirejo

Ĉe la enirejo, ŝaltu plusendadon por la familio, kiun vi portas, permesu la forward-ĉenon en ambaŭ direktoj, kiam vi tradukas, kaj konfirmu la revenan vojon per fontospecifa serĉado. Nenio el tio sekvas el sukcesa manpremo, ĉar manpremo nur pruvas, ke la du kunuloj povas interŝanĝi UDP. Ĝi diras nenion pri tio, kio okazas poste al la malkapsuligita paketo.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

La serĉado ruliĝas ĉe la enirejo, ne ĉe la kliento, alie vi legos alian enrutan tabelon. Se ĝi nomas la malĝustan interfacon, aŭ raportas neniun itineron, tiam neniu klientflanka ŝanĝo produktos interretan eliron. Kiam la enirejo tradukas klientajn adresojn survoje eksteren, la respondo dependas de tiu traduka stato, do la regulo devas ekzisti por ambaŭ direktoj de la fluo kaj ne nur por la elira.

DNS kaj la fiaska stato, aparte testitaj

La protokolo mem agordas la solvilon de neniu aplikaĵo. wg-quick aplikas la linion DNS per la solvila integriĝo de la distribuo, ujoj kaj retumiloj kun propraj stakoj povas ignori ĝin, kaj tial nomo povas fiaski dum la tunelo portas pakaĵojn perfekte. Testu per gastiganta nomo anstataŭ adreso, kaj notu, kiu servilo respondis, anstataŭ supozi, ke la servilo en la profilo faris tion.

Adresaj familioj estas aparta testo kun aparta respondo. Defaŭlta itinero v4 diras nenion pri tio, kion faros la v6-konekto de aplikaĵo, kaj tunelo, kiu silente likas la duan familion, estas pli malbona ol tiu, kiu laŭte fiaskas. Demandu nomon tra ĉiu familio, legu la interfacon, kiun uzis ĉiu peto, kaj kontrolu la tradukajn nombrilojn antaŭe kaj poste, ĉar regulo, kiu kongruas kun nenio, aspektas idente al mankanta regulo.

Fine, testu la staton, kiun vi volas, kiam la tunelo haltas. Plena tunelo devus fiaski fermite por la trafiko, kiun ĝi pretendas: se la interfaco faliĝas kaj aplikaĵoj silente daŭras tra la fizika ligo, la dezajno estas dividita tunelo kun kromaj paŝoj. Skribu la celatan fiaskan konduton, kontrolu ĝin intence, kaj finu registrante la kvar respondojn — kiu administrilo levas la interfacon, kiu itinero portas la defaŭltan, kiu plusendas kaj tradukas ĉe la enirejo, kaj kiu solvilo respondas.