Com donar a una LAN de proves la seva pròpia sortida WireGuard
Limiteu una LAN a una sortida WireGuard amb una taula d'encaminament dedicada i un guardià inabastable, mentre la passarel·la conserva la seva ruta per defecte WAN habitual.
Tres dissenys resolen el mateix problema de laboratori: una LAN petita que ha de sortir per un parell WireGuard mentre la passarel·la conserva el seu enllaç ascendent habitual. La drecera temptadora és moure la ruta per defecte de l'encaminador dins del túnel, cosa que trenca el camí de gestió propi de la caixa i tot el que reenvia. L'opció interessant és l'encaminament per política limitat a una interfície i un prefix. Trieu entre ells responent tres preguntes sobre la màquina que realment teniu.
Decidiu on viu la sortida
Primera pregunta: aquest amfitrió reenvia per a alguna altra cosa? Una passarel·la de laboratori dedicada pot viure amb una política de reenviament que descarta per defecte. Un encaminador amb deures de producció no pot, i superposar un conjunt de regles competitiu sobre un tallafoc gestionat és exactament com es programen les caigudes. Segona: podeu posseir dos objectes de política i el seu ordre entre reinicis? Tercera: el parell que teniu autoritza l'adreça d'origen del túnel i ofereix sortida a internet? Un parell que només exposa una xarxa privada és un producte diferent, i cap canvi local d'encaminament ho arregla. Si qualsevol resposta és no, poseu la sortida en un espai de noms o en una màquina virtual d'un sol ús.
Un espai de noms o una VM costen memòria i us donen un radi d'impacte net. L'encaminament per política costa dues regles i us deixa una sola caixa per depurar.
Trieu la sortida que autoritza el vostre origen
La majoria de fallades d'aquest laboratori passen abans que existeixi una sola regla de tallafoc. L'operador de la sortida ha d'acceptar l'adreça d'origen que porten els vostres paquets després de la traducció, que en aquest disseny és l'adreça del túnel i no el prefix de la LAN. Per això l'emmascarament pertany al disseny des del principi i no com a afegit tardà.
Confirmeu tres coses amb l'operador: el parell autoritza l'adreça del vostre túnel, reenvia IPv4 en lloc d'acabar en si mateix i aplica NAT de sortida. Sense la primera, els vostres paquets arriben i desapareixen. Sense la tercera, surten amb un origen privat i moren al següent salt. Després comproveu que wg-quick no instal·la la seva pròpia ruta per defecte, cosa que evita Table = off; aquest paràmetre suprimeix la creació de rutes, no les comprovacions d'AllowedIPs del parell ni la seva gestió de DNS.
Dos objectes de política fan la direcció
La direcció necessita una taula i una regla. La taula conté dues rutes: el prefix de la LAN fora de la interfície LAN i una ruta per defecte fora del túnel. La regla envia el trànsit que arriba per la interfície LAN i porta aquest prefix cap a la taula. Feu servir el selector iif al costat de la coincidència d'origen, perquè els paquets WireGuard propis de la passarel·la s'originen localment i mai no coincideixen amb una interfície entrant.
El guardià va abans de la consulta, no després. Aquest ordre és tota la propietat de seguretat del disseny.
El guardià és una segona regla sobre el mateix selector el veredicte de la qual és unreachable. Doneu-li una prioritat numèrica més alta perquè la consulta segueixi guanyant mentre el túnel està aixecat. Quan la ruta del túnel desapareix, la consulta no retorna res i el guardià atura la cerca en lloc de deixar-la caure a la ruta per defecte WAN de la taula principal.
ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0
Tanqueu l'esquerda de retrocés abans d'obrir-la
Instal·leu primer el guardià i la consulta després. Fer-ho a l'inrevés deixa una finestra de segons durant la qual el trànsit d'un client de proves pot arribar a l'enllaç ascendent.
El filtre completa el quadre. Al ganxo forward, accepteu la direcció de LAN a túnel per al prefix de proves i la direcció de retorn establerta, i després descarteu tota la resta; el NAT d'aquest prefix cap a la interfície del túnel va a postrouting. Deixar policy drop a la cadena de reenviament és el que converteix una ruta absent en silenci en lloc d'una fuita. El filtratge de camí invers necessita mode lax a la interfície del túnel, perquè un origen públic que arriba desencapsulat té la seva millor ruta inversa al costat WAN. Linux pren el valor més alt entre all i el de la interfície, així que configurar la interfície del túnel no és el mateix que debilitar la validació a tot arreu.
Demostreu-ho amb el cas de fallada
Pregunteu al nucli una pregunta precisa tot anomenant l'adreça d'origen del client i la interfície per la qual arriba. Una consulta sense totes dues respon una altra pregunta i semblarà correcta en tots dos casos. Després mireu els comptadors del tallafoc, l'estat de transferència del parell i el servei propi del client.
Proveu la retirada com cal. Atureu el túnel deixant la regla i el filtre al lloc: el client hauria d'encallar-se i el trànsit propi de la passarel·la hauria de continuar funcionant. Després atureu el parell sense tocar la interfície local, que és el cas que enxampa els dissenys que es refien només de la presència de la ruta. Finalment reinicieu i torneu a comprovar l'ordre de les regles, perquè un ganxo de desmuntatge que elimina el guardià torna tot el disseny a la taula principal. Anoteu el número de taula, les prioritats i els noms d'interfície al tiquet de canvi, perquè la propera persona que afegeixi una regla serà la que ho trencarà.