Zona VPN d’OpenWrt, reenviament i emmascarament: què cal?

Tres canvis es barregen sempre que una VPN es troba amb OpenWrt: obrir un port, permetre el reenviament i activar l’emmascarament. Responen a preguntes diferents, i normalment només un d’ells és el requisit real. Llegir cada control segons el paper del trànsit que governa converteix un supòsit en una decisió, i també diu quin símptoma esperar quan el canvi és incorrecte. Comenceu anomenant el paper que ha fallat, no la casella que recordeu.

Anomeneu el paper del trànsit abans de tocar cap control

L’entrada de zona decideix què pot arribar al router mateix. La sortida de zona cobreix el trànsit que origina el router, el reenviament de zona és el valor per defecte per al trànsit que passa per una zona, i l’emmascarament decideix si l’adreça d’origen es reescriu a la sortida. Són quatre preguntes diferents, i una política de zona les respon totes alhora amb el mateix valor, per això un canvi a tota la zona és un instrument groller. Una regla amb nom pot respondre’n una sense tocar les altres.

El mapa útil és per paper del trànsit, perquè això és el que podeu observar quan alguna cosa falla. Cada paper de sota té un control que el decideix i un símptoma que hi apunta:

Un servei d’escolta al router necessita una sola regla d’entrada estreta

Un servidor OpenVPN al router rep trànsit adreçat al router, així que la seva connexió exterior depèn de la política d’entrada de la zona que el transporta. Permeteu el transport i el port configurats i deixeu la resta d’aquella zona en rebuig. Una sola regla de port és un canvi molt més petit que una acceptació a tota la zona, i és la que encara podreu explicar d’aquí a un any.

Dues coses fan que aquesta regla sigui segura de mantenir: anomena el port que el servei fa servir de debò i està al costat de la definició de la zona perquè la propera persona vegi per què existeix. Les línies de sota són la forma, amb el port fent de substitut del que tingui configurat el servidor. Canvieu aquest port als dos llocs quan el servei es mogui, perquè una regla que es queda al vell és invisible fins a una auditoria.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Valideu abans de recarregar, perquè un error de sintaxi en un fitxer de tallafocs pot deixar el router sense un conjunt de regles funcional. En una versió que fa servir fw4 la comprovació és una ordre a part, i falla sorollosament en lloc d’acceptar en silenci un bloc trencat. Recarregueu només després que la comprovació passi i guardeu el fitxer anterior allà on el pugueu posar de tornada.

fw4 check
service firewall reload

La petició d’un client passa pel reenviament, no per l’entrada

Després de l’autenticació, la petició d’un client de túnel a un servei de la LAN produeix un flux reenviat, així que el control que la decideix és la relació de reenviament entre la zona del túnel i la zona LAN. Assigneu la interfície del túnel a la zona volguda i després declareu la direcció, les fonts i el servei. L’assignació de zona és el que dona sentit a la regla de reenviament, i les dues coses només s’entenen llegides juntes. Una relació de reenviament que anomena la zona del túnel com a origen i la zona LAN com a destinació es llegeix com una decisió deliberada, mentre que dues acceptacions a tota la zona es llegeixen com un accident.

Arribar al router mateix encara fa servir el camí d’entrada, per això un ping a la passarel·la no diu res sobre el recurs compartit que hi ha darrere. Aquests dos fracassos viuen en blocs diferents i es reparen amb edicions diferents. Escriviu els dos camins per separat abans de canviar-ne qualsevol.

L’emmascarament és una decisió d’encaminament, no un permís

L’emmascarament reescriu l’adreça d’origen del trànsit de sortida seleccionat. Pot rescatar un disseny de sortida en què el costat llunyà no té ruta de tornada, i també amaga les adreces dels clients individuals de qualsevol servei que registri o autoritzi per adreça. Desactivar-lo és una tria d’encaminament sobre el camí de tornada, no un interruptor de seguretat que tanca un forat d’entrada. Un túnel que funciona amb la traducció activada i falla en el moment de desactivar-la sol tenir una ruta de tornada que falta, no una regla de tallafocs que falta.

L’alternativa encaminada necessita una ruta de tornada al costat llunyà en lloc de la traducció. Cap de les dues opcions no proporciona el permís del tallafocs ni el compte de l’aplicació, per això desactivar l’emmascarament gairebé mai no arregla un client de túnel que no pot arribar enlloc. Tracteu també la política IPv4 i la IPv6 per separat, perquè un sol paràmetre de traducció no descriu les dues famílies.

Demostreu la decisió amb una petició permesa i una de rebutjada

Envieu una petició que s’hauria de permetre i una que s’hauria de rebutjar, i després identifiqueu el control que ha pres cada decisió. Una pàgina que es carrega per casualitat no és prova; la prova és la regla que ha coincidit, a la cadena on ha coincidit. El rebuig importa tant com l’èxit, perquè mostra que la política fa alguna cosa en lloc que tot estigui permès.

Dues ordres us donen aquesta prova en una versió actual. El comptador de la regla corresponent es mou quan la petició s’accepta, i el registre mostra el descart si heu activat el registre per a la regla:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Conserveu un camí d’administració que encara pugueu fer servir abans de canviar qualsevol política de tallafocs, i seguiu el procés de validació i reversió del propietari de la configuració. Un canvi que us deixa fora del router no és un resultat de prova, és un segon incident. Anoteu la zona i el paper del trànsit al costat de cada observació, perquè el parell de resultats expliqui la política en lloc de descriure una càrrega de pàgina afortunada.