Clients VPN i la LAN: quan cal una zona separada

Posar la interfície del túnel a la zona de la LAN és el camí més curt cap a una VPN que funciona, i normalment és el valor per defecte equivocat. Atorga al client remot la mateixa confiança que té la LAN cablejada, cosa que la tasca poques vegades exigeix. Una zona separada costa unes quantes regles i fa visible la frontera. La decisió no és si les zones són millors; és quines tres condicions s’apliquen a la vostra xarxa.

El nom de la zona no xifra res ni autentica cap usuari. Només agrupa interfícies per al model de polítiques del tallafoc.

Què controla realment la pertinença a una zona

Una zona agrupa interfícies o trànsit dins del model del tallafoc. Després, la seva configuració d’entrada, sortida i reenviament governa rols diferents. L’entrada és el trànsit cap al mateix encaminador; el reenviament és el trànsit que el travessa cap a un altre amfitrió. La documentació d’OpenWrt sobre zones tracta entrada, sortida i reenviament com a paràmetres separats exactament per aquest motiu.

Un permís de la zona VPN cap a la zona LAN no és automàticament un permís invers. Les regles de reenviament són direccionals, i una regla que permet trànsit de client a servidor no permet sessions de servidor a client. Un client que pot obrir una connexió cap a un servidor no és un client cap al qual el servidor pugui obrir una connexió de tornada.

Aquesta distinció és la raó per la qual una zona separada és útil: podeu declarar cada direcció i cada rol explícitament. Escriviu la direcció al costat de cada regla.

Decisió primera: entrada, reenviament o totes dues

Si els clients remots necessiten DNS de l’encaminador, permeteu entrada només per a aquest servei. Si necessiten arribar a un servidor de fitxers, permeteu reenviament cap a aquesta destinació. La majoria de dissenys VPN necessiten totes dues coses, però per a serveis diferents.

L’accés ampli d’entrada a tots els serveis locals gairebé mai no cal. Tracteu la gestió de l’encaminador com una decisió separada de l’accés a aplicacions. Si l’encaminador només ha de respondre DNS, escriviu aquest únic permís i deixeu la resta tancat.

Decisió segona: quins recursos necessiten els clients remots

Llisteu els rangs de clients, les destinacions i els serveis que la VPN hauria de proporcionar abans d’escriure regles. Una llista de destinacions és més útil que una etiqueta de confiança, perquè sobreviu a una migració del tallafoc.

Manteniu les interfícies de gestió separades de l’accés habitual a les aplicacions. Un client remot que pot arribar a un wiki no necessita per això la pàgina d’administració de l’encaminador ni la consola de l’hipervisor.

Si una destinació permesa pot reenviar més enllà, la frontera de la zona s’atura al tallafoc, no en el que la destinació fa després.

Decisió tercera: com demostrareu la frontera

Proveu un flux permès i un de denegat deliberadament després de cada canvi. Demostrar que un lloc web carrega no revela un permís ampli no intencionat. Proveu des del rang d’adreces del client VPN, no des de la LAN, i incloeu la direcció que espereu que falli. Anoteu tots dos resultats al costat de la regla.

Preserveu l’accés de recuperació de la passarel·la abans de modificar la política de la zona remota. Feu servir la configuració gestionada persistent en lloc d’edicions en temps d’execució, o el proper reinici restaurarà l’antiga confiança. Una còpia de la configuració anterior, guardada fora del dispositiu, és la reversió més barata que tindreu mai.

Quan la xarxa creixi, documenteu la pertinença i el propòsit de les regles. Una interfície recentment connectada no hauria d’heretar privilegis només perquè algú li va donar un nom de zona convenient.