Posar 0.0.0.0/0, ::/0 a l’AllowedIPs d’un peer és el pas que tothom recorda, i només decideix quin trànsit se li permet transportar. Aquests prefixos no creen cap ruta, no reenvien res a l’altre costat i deixen el resolutor de cada aplicació exactament on era. Quatre coses separades han de complir-se alhora perquè un túnel complet sigui complet, i és millor comprovar-les en l’ordre d’aquí sota, perquè una comprovació posterior no pot rescatar una d’anterior. Cada comprovació d’aquí sota és un fet que es pot llegir d’una màquina, no un paràmetre que esperes que s’hagi aplicat.

Què tria el prefix del peer i què no

AllowedIPs és alhora un selector i un autoritzador. Diu al costat local quines destinacions es poden enviar a aquest peer, i diu al costat receptor quines adreces d’origen pot presentar aquest peer. Aquesta és tota la feina. Res d’aquesta descripció no crea una ruta a l’amfitrió, no activa el reenviament al costat remot ni toca la resolució de noms.

Per això una configuració pot semblar completa i comportar-se com un túnel dividit. El prefix diu que el peer acceptaria tot; la taula d’encaminament de l’amfitrió decideix què hi arriba realment, i la passarel·la decideix si en surt res. Cap d’aquestes tres decisions no viu a l’estrofa del peer.

Encaminar el client, no només la llista de peers

Gestors com ara wg-quick programen la taula d’encaminament de l’amfitrió per tu, i per això dos fitxers de configuració idèntics es comporten diferent segons com s’ha aixecat la interfície. Un perfil mínim és prou curt per llegir-lo d’una tirada:

[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

Dos detalls porten la feina. El camp Address és un prefix d’amfitrió únic en lloc d’una subxarxa que el client creu que posseeix, i és el gestor qui converteix l’AllowedIPs per defecte en una ruta per defecte real. Aixeca el mateix fitxer amb ip link i wg setconf i no apareixerà cap ruta, cosa que sembla un túnel trencat i en realitat és un túnel sa amb el pas d’encaminament omès. El manual de wg-quick documenta l’encaminament i el Table comportament que aquests gestors afegeixen.

Llegeix el resultat en lloc del fitxer: ip route get 1.1.1.1 hauria de nomenar la interfície del túnel, i wg show hauria de reportar un handshake recent amb un comptador de transferència que es mou. Un handshake sense ruta vol dir que el gestor no s’ha executat mai, i editar el perfil una altra vegada no ho arreglarà. Inicia la interfície tal com ho farà l’usuari, o la prova mesura la teva shell en lloc del desplegament.

Mantenir l’extrem fora del túnel

Un túnel complet captura cada destinació, inclosa la que ha de parlar per existir. Els gestors ho resolen afegint una ruta d’amfitrió per a l’extrem a través de la passarel·la original, i per això una configuració correcta gairebé sempre conté una excepció deliberada. Aplicar la meitat de la configuració amb un gestor i l’altra meitat a mà és la manera habitual que aquesta excepció es perdi.

Si l’extrem és un nom d’amfitrió que resol a diverses adreces, o a una família que no transportes, l’excepció envelleix malament i el túnel pot fallar després d’una reconnexió que semblava rutinària. Fixa l’extrem a una adreça que controlis, o confirma que el gestor la reavalua, i torna a llegir la ruta d’amfitrió després de cada canvi de xarxa.

El mateix mecanisme explica per què un túnel complet i un portal captiu es barallen. El portal espera interceptar el trànsit que ara captura el teu túnel, així que en xarxes d’hotel i d’aeroport aixeques el túnel després de l’inici de sessió del portal, mai abans.

Reenviament i camí de tornada a la passarel·la

A la passarel·la, activa el reenviament per a la família que transportes, permet la cadena forward en tots dos sentits quan tradueixes, i confirma el camí de tornada amb una consulta específica d’origen. Res d’això no es dedueix d’un handshake correcte, perquè un handshake només demostra que els dos peers poden intercanviar UDP. No diu res sobre què passa després amb el paquet desencapsulat.

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

La consulta s’executa a la passarel·la i no al client, o llegiràs una altra taula d’encaminament. Si nomena la interfície equivocada, o informa que no hi ha ruta, llavors cap canvi al costat del client produirà una sortida a internet. Quan la passarel·la tradueix les adreces dels clients a la sortida, la resposta depèn d’aquell estat de traducció, així que la regla ha d’existir per als dos sentits del flux i no només per al sortint.

DNS i l’estat de fallada, provats per separat

El protocol mateix no configura el resolutor de cap aplicació. wg-quick aplica la línia DNS a través de la integració del resolutor de la distribució, els contenidors i els navegadors amb les seves pròpies piles la poden ignorar, i per tant un nom pot fallar mentre el túnel porta paquets perfectament. Prova amb un nom d’amfitrió en lloc d’una adreça, i anota quin servidor ha respost en lloc de suposar que ho ha fet el del perfil.

Les famílies d’adreces són una prova separada amb una resposta separada. Una ruta per defecte v4 no diu res sobre què farà la connexió v6 d’una aplicació, i un túnel que filtra en silenci la segona família és pitjor que un que falla sorollosament. Consulta un nom per cada família, llegeix la interfície que ha fet servir cada petició, i comprova els comptadors de traducció abans i després, perquè una regla que no coincideix amb res sembla idèntica a una regla que falta.

Finalment, prova l’estat que vols quan el túnel s’atura. Un túnel complet hauria de fallar tancat per al trànsit que reclama: si la interfície cau i les aplicacions continuen en silenci per l’enllaç físic, el disseny és un túnel dividit amb passos extra. Escriu el comportament de fallada previst, comprova’l deliberadament, i acaba registrant les quatre respostes — quin gestor aixeca la interfície, quina ruta porta la per defecte, qui reenvia i tradueix a la passarel·la, i quin resolutor respon.

Articles relacionats