Passarel·la VPN de Windows: tres feines, tres responsables

Tres funcions s’ajunten sempre que algú diu servidor VPN: tancar el túnel xifrat, moure paquets entre xarxes i, opcionalment, reescriure adreces. A Windows viuen en parts diferents de la pila, fins i tot quan una sola màquina les fa totes. Cadascuna té les seves entrades i la seva pròpia manera de fallar, i cadascuna es pot encarregar a un producte diferent. Separar-les sobre el paper és la manera més barata de mantenir comprensible un desplegament petit.

Un disseny llegible anomena el responsable de cada flux en lloc de descriure la màquina com un rol.

Tancar, encaminar, traduir

RRAS gestiona el túnel per al cas natiu de Windows: autentica l’usuari, assigna una adreça d’un pool i decideix quines destinacions es permeten. Un altre producte VPN pot encarregar-se del receptor i de l’adaptador virtual, i deixar que Windows encamini els paquets desxifrats. La documentació de Remote Access de Microsoft separa els rols de VPN, lloc a lloc i encaminament, i instal·lar el rol d’encaminament no crea una segona identitat VPN. Afegir una altra aplicació VPN tampoc no lliura el seu adaptador a totes les funcions de passarel·la existents.

La traducció és la tercera feina i la més opcional. Va després de l’encaminament i canvia l’adreça d’origen que veu la xarxa remota. Si la necessiteu depèn del que la xarxa de destinació acceptarà com a origen, no del fet que la màquina es digui passarel·la VPN.

Qui és el responsable de l’adaptador i del pool

Quan diversos productes comparteixen l’amfitrió, quatre coses necessiten un sol responsable cadascuna: els ports d’escolta, la vida de l’adaptador, el pool d’adreces de clients i les rutes. L’adaptador és el més incòmode, perquè un servei VPN pot crear-lo dinàmicament i destruir-lo en desconnectar. Tractar aquesta interfície com una targeta de xarxa amb nom permanent i escriure regles contra el seu nom funciona fins a la propera reconnexió. Feu servir el punt d’integració suportat pel producte en lloc de codificar el nom d’una interfície.

El pool d’adreces és la segona col·lisió. Dos productes que reparteixen rangs superposats produeixen un encaminament que sembla correcte i no lliura res. Manteniu els pools al mateix document que les rutes, de manera que un canvi en un sigui visible contra l’altre.

Preservar l’origen o reescriure’l

Preservar l’adreça d’origen del client manté la visibilitat per usuari: els registres, les quotes i les regles de tallafocs poden distingir un usuari d’un altre. El preu és que la LAN de destinació necessita una ruta de retorn cap a la passarel·la, i algú l’ha de mantenir. Reescriure l’origen amb NAT elimina aquest requisit i elimina la visibilitat amb ell. Trieu deliberadament i anoteu quina informació amaga la reescriptura.

L’accés a la xarxa privada, la sortida a internet i les connexions que acaben a la mateixa passarel·la són tres camins diferents. No tots necessiten el mateix tracte.

Descriure el flux en una frase

Una frase hauria de descriure el disseny: quins clients admet aquest servei, quins recursos concedeix aquesta política d’encaminament i com el camí de tornada completa el flux. Si la frase necessita una segona capa de NAT per ser certa, normalment és senyal que les peces anteriors no estaven resoltes. L’amfitrió també és una frontera compartida de fallada i de confiança, així que un canvi d’encaminament pot afectar tant l’accés dels usuaris com l’administració. Manteniu un camí de recuperació independent per a aquesta última.

Manteniu un inventari de rols al costat de la configuració: quin producte tanca, quin encamina, quin tradueix i qui pot canviar cadascun. Aquesta llista és el que fa revisable el proper canvi.

Quan la frase es torna confusa, afegir una altra capa de traducció poques vegades l’aclareix. Treure’n una normalment sí.