Limiteu una passarel·la OpenVPN a una LAN amb regles d'UFW

Decidiu el permís abans d'obrir un fitxer de tallafocs: els clients autenticats poden obrir connexions a una subxarxa concreta, i la passarel·la ha de refusar qualsevol altre camí de trànsit fins i tot quan un client instal·li rutes addicionals. Aquesta frase és el disseny, i cada regla de sota existeix per fer-la complir. Qualsevol cosa més àmplia, com tot l'espai d'adreces privades, la sortida a internet pel túnel o el trànsit entre iguals, és un disseny diferent que necessita la seva pròpia decisió. Les regles també són deliberadament avorrides, perquè un tallafocs enginyós és un que ningú no podrà auditar després.

Escriviu primer la topologia i el permís

L'exemple utilitza un servidor Community OpenVPN amb un dispositiu TUN d'espai d'usuari anomenat tun0, un pool de clients 10.77.0.0/24, i una subxarxa connectada 192.168.60.0/24 a lan0. El reenviament IPv4 ja funciona i la LAN ja té una ruta de tornada al pool, així que res aquí depèn de la traducció entre ells.

UFW és l'amo del tallafocs en aquest amfitrió, i cap conjunt de regles de contenidor ni cap taula nftables separada no pot instal·lar un camí d'acceptació anterior. Un drecera de descàrrega de flux que salti el filtre faria decoratives les cadenes de guàrdia, així que confirmeu que no n'hi ha cap d'activa. Deixeu el reenviament client-to-client propi d'OpenVPN desactivat, perquè el trànsit entre iguals que no travessa mai el filtre del sistema operatiu no es pot limitar amb ell. L'oïdor extern i les regles d'administració es queden com estan, ja que aquest canvi governa el trànsit desxifrat del túnel en lloc de substituir el tallafocs.

Col·loqueu les guàrdies abans de les acceptacions primerenques d'UFW

Un permís de ruta seguit d'una denegació no n'hi ha prou per a una frontera estricta. Les regles before de sèrie accepten el trànsit establert i uns quants ICMP abans que es consulti qualsevol regla d'usuari, així que un flux permès la setmana passada pot quedar fora de la nova restricció de destinació només perquè encara té estat. Feu una còpia de seguretat dels fitxers d'UFW i manteniu una consola fora de banda oberta abans d'editar.

A la secció *filter del fitxer /etc/ufw/before.rules, declareu dues cadenes al costat de les declaracions existents i abans de qualsevol línia de regla.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Just després de les declaracions, i abans dels permisos d'entrada i de reenviament, salteu-hi i definiu què admeten.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Conserveu la resta de la secció i la seva línia COMMIT. Enganxar una segona taula de filtre o esborrar regles no relacionades és com un canvi de tallafocs es converteix en una caiguda, i el fitxer és a un reinici de ser l'única còpia que importa.

Llegiu què admet i refusa cada guàrdia

La primera cadena continua el processament només quan l'origen és dins del pool, la destinació és l'única subxarxa, la interfície de sortida és la LAN i el paquet viatja en la direcció original del seu flux. Tota la resta que arriba del túnel es descarta, inclosa una font fora del pool i qualsevol destinació més enllà de la subxarxa permesa.

Un paquet entre iguals entra i surt per tun0, així que falla la prova d'interfície de la LAN abans i tot d'arribar a la comprovació de destinació. Les connexions noves de la LAN cap als clients també fallen la prova de direcció de resposta, cosa que tanca per defecte el camí de trucada inversa.

L'objectiu RETURN manté la política normal d'UFW en joc. Aquestes cadenes filtren, i el permís de ruta que afegiu després encara decideix si un paquet supervivent s'accepta. Aquesta separació és el que us permet canviar la subxarxa permesa en un sol lloc més endavant. Si les guàrdies acceptessin els paquets directament, cada regla futura s'hauria d'afegir dues vegades.

Autoritzeu la subxarxa i tanqueu les portes laterals

Previsualitzeu primer el permís de ruta i després traieu la marca de previsualització per aplicar-lo: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Després reviseu l'ordre de les regles d'usuari, perquè una denegació anterior encara guanya una autorització posterior. Un permís per a tota la subxarxa també és la forma equivocada quan només el port HTTPS d'un amfitrió ha de ser accessible.

Fixeu-vos en què fa el descartament d'entrada: els clients del túnel no poden arribar a cap servei de la mateixa passarel·la, inclòs un oïdor DNS lligat a la seva adreça de LAN. Allotjar-hi DNS necessita una excepció deliberada abans del descartament i un contracte de permís revisat. Si UFW gestiona IPv6, afegiu descartaments corresponents per a tun0 a before6.rules també, perquè una llista de destinacions IPv4 no diu res sobre els paquets IPv6.

Verifiqueu la política carregada, no la previsualització

Previsualitzeu la recàrrega, apliqueu-la en una finestra de manteniment i llegiu el conjunt de regles viu.

sudo ufw --dry-run reload
sudo ufw show raw

Confirmeu que les guàrdies del túnel apareixen abans dels permisos per defecte d'estat i ICMP. L'ordre ufw status simple no mostra les regles before editades a mà, i per això els operadors conclouen que falta una regla quan en realitat està carregada. Llegiu el llistat cru de dalt a baix en lloc de buscar un fragment. Si les guàrdies apareixen després d'un permís d'estat, la frontera no fa el que el fitxer suggereix.

Després proveu el comportament, no el text. Obriu una connexió nova a un amfitrió permès i observeu la resposta, encamineu una petició innòcua a una destinació fora de la subxarxa i confirmeu que mor, proveu una connexió entre iguals, proveu un servei local de la passarel·la i proveu una connexió no sol·licitada de la LAN cap a un client. Incloeu un flux fora d'abast que existís abans del canvi, i esborreu només aquest flux en lloc de buidar tota la taula de seguiment de la màquina.

Anoteu els límits al costat de les regles: això limita el trànsit i res més. No impedeix que un client utilitzi la seva pròpia connexió a internet, no impedeix que un amfitrió permès de la LAN retransmeti trànsit més enllà, i no substitueix l'autenticació dins dels serveis permesos.