Com encaminar un únic lloc web fora del vostre túnel WireGuard

Excloure un nom d'amfitrió és una cosa que un túnel no pot fer. Una ruta, però, pot enviar una sola adreça més enllà del túnel i cap a fora per la passarel·la de casa, i normalment n'hi ha prou per a un lloc. La trampa és que tot el que hi ha després de la ruta ha de coincidir: el tallafoc ha de deixar sortir el paquet, el DNS ha de tornar l'adreça que heu encaminat i el lloc ha de continuar utilitzant aquesta adreça. Quan qualsevol dels tres es desvia, l'excepció deixa de funcionar sense anunciar-se.

Llegiu l'adreça de destinació abans de tocar el túnel

Carregueu el lloc una vegada amb el túnel actiu i després mireu l'adreça del parell a la qual el navegador s'ha connectat realment. A Linux, ss -tunp llista l'adreça remota de cada sòcol obert, i dig +short sobre el mateix nom mostra què ha retornat el resolutor. Tingueu els dos números al davant.

Les dues respostes sovint no coincideixen, i aquesta discrepància és tot el problema. Els llocs grans posen una xarxa de continguts davant del seu origen, així que l'adreça que el resolutor retorna ara pot no ser la que el navegador va utilitzar fa un minut. Encamineu el que heu observat al sòcol, no el que llista una guia antiga. Si les respostes no paren de rotar entre regions, una excepció d'adreça és l'instrument equivocat per a aquest lloc concret.

Executeu la consulta una segona vegada des d'una altra xarxa i anoteu la resposta IPv6 juntament amb la IPv4. Un túnel que transporta les dues famílies necessita una excepció en totes dues, si no el navegador recau en silenci cap al camí IPv6 que mai no heu tocat. Poseu les adreces i la data en un lloc on hi torneu a mirar.

Poseu una ruta d'amfitrió al client

Suposem que la interfície es diu home-wg i que el router LAN és a 192.168.1.1. NetworkManager agafa una ruta la passarel·la de la qual és aquest router i la longitud de prefix de la qual cobreix els 32 bits sencers, i el nucli la prefereix perquè el prefix més llarg guanya.

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 passarel·la ha de ser abastable sense el túnel; apuntar el salt següent a l'adreça del túnel enganya el propòsit, perquè el paquet tornaria a entrar a la interfície que intenteu evitar. Quan la connexió torna a aixecar-se, ip route get per a l'excepció hauria d'imprimir la passarel·la LAN, i la mateixa ordre per a un resolutor públic encara hauria d'imprimir el dispositiu del túnel.

Un perfil wg-quick no té camp de rutes, així que la mateixa excepció viu en una línia PostUp que afegeix la ruta d'amfitrió a la taula principal amb la interfície LAN com a dispositiu. Baixeu i torneu a aixecar la interfície després d'editar, perquè una interfície en marxa mai no torna a llegir el seu fitxer. Les regles fwmark que instal·la wg-quick només dirigeixen els seus propis paquets encapsulats, així que el trànsit normal del navegador continua seguint la taula principal i troba el vostre /32.

L'interruptor d'emergència és la següent cosa que ho bloqueja

Una política de tallafoc que només admet trànsit a la interfície del túnel descartarà l'excepció fins i tot quan la ruta sigui exactament correcta. Llegiu les regles que hi ha darrere del commutador en lloc de confiar en el commutador, perquè les que implementen un interruptor d'emergència solen estar limitades a un nom d'interfície.

El que voleu és un permís estret per a la interfície física i aquella única destinació, col·locat abans del descart, mentre la política per defecte queda intacta. Aturar del tot l'interruptor d'emergència demostra el punt, però també deixa la màquina exposada mentre us oblideu de tornar-lo a engegar.

Proveu les dues direccions per separat. Una petició a l'adreça de l'excepció hauria de reeixir mentre una petició a un lloc no relacionat encara surt pel túnel. Si totes dues reeixen però la segona informa de l'adreça de casa, l'ordre de les regles del tallafoc és incorrecte, no la ruta.

El DNS decideix a quina adreça marca el navegador

Quan el nom es resol dins del túnel, el resolutor del proveïdor pot respondre amb una adreça diferent de la que va donar el local. Llavors la vostra ruta s'aplica a una adreça que el navegador no contacta mai, i la pàgina es carrega pel túnel com si no hagués canviat res. Aquesta fallada sembla una excepció trencada encara que la taula d'encaminament sigui correcta.

Envieu també les consultes d'aquest nom a través del resolutor local, o salteu-vos els noms del tot i proveu l'adreça directament. Separar l'adreça mentre el DNS es queda dins del túnel és la versió mig feta més habitual d'aquesta configuració, i també la més difícil de notar, perquè el lloc continua funcionant, només que no com volíeu.

La mateixa excepció al router, una vegada, per a cada dispositiu

Amb el túnel funcionant al router, la ruta d'amfitrió pertany a la taula d'encaminament per polítiques del router i apunta a la passarel·la WAN en lloc de la LAN. Cada dispositiu que hi ha darrere n'hereta l'excepció, cosa que importa per a una caixa d'streaming o un portàtil de feina les configuracions de xarxa del qual no podeu canviar.

Deixeu el túnel com a sortida per defecte per a tots els altres clients i després verifiqueu-ho des d'una màquina client, no des de la consola del router. Carregueu el lloc de l'excepció i un segon lloc a la mateixa sessió del navegador i compareu les adreces de sortida; si el segon encara mostra el túnel, la taula de polítiques fa el que li heu demanat.

Anoteu l'adreça, la data i el motiu a les notes del router. Una excepció construïda al voltant d'una adreça que després es mou es converteix en una fallada que ningú no pot explicar d'aquí a un any, i la solució sempre sembla un misteri fins que algú troba la nota antiga.