Pasarela VPN de Windows: tres tarefas, tres responsables

Tres funcións agrúpanse cada vez que alguén di servidor VPN: pechar o túnel cifrado, mover paquetes entre redes e, opcionalmente, reescribir enderezos. En Windows viven en partes distintas da pila, mesmo cando un só equipo as fai todas. Cada unha ten as súas propias entradas e a súa propia forma de fallar, e cada unha pode entregarse a un produto distinto. Separaas sobre o papel é a forma máis barata de manter comprensible un despregamento pequeno.

Un deseño lexible nomea o responsable de cada fluxo en lugar de describir o equipo como un rol.

Pechar, reenviar, traducir

RRAS encárgase do túnel no caso nativo de Windows: autentica o usuario, asigna un enderezo dun grupo e decide que destinos están permitidos. Outro produto VPN pode posuír o receptor e o adaptador virtual, e deixar que Windows reenvíe os paquetes descifrados. A documentación de Remote Access de Microsoft separa os roles de VPN, sitio a sitio e enrutamento, e instalar o rol de enrutamento non crea unha segunda identidade VPN. Engadir outra aplicación VPN tampouco entrega o seu adaptador a todas as funcións de pasarela existentes.

A tradución é a terceira tarefa e a máis opcional. Vén despois do reenvío e cambia o enderezo de orixe que ve a rede remota. Se a necesita depende do que a rede de destino acepte como orixe, non de que o equipo se chame pasarela VPN.

Quen é dono do adaptador e do grupo

Cando varios produtos comparten o host, catro cousas necesitan un único dono cada unha: os portos de escoita, a vida do adaptador, o grupo de enderezos de clientes e as rutas. O adaptador é o incómodo, porque un servizo VPN pode crealo de forma dinámica e destruílo ao desconectar. Tratar esa interface como unha tarxeta de rede con nome permanente e escribir regras contra o seu nome funciona ata a seguinte reconexión. Use o punto de integración soportado polo produto en lugar de codificar o nome dunha interface.

O grupo de enderezos é a segunda colisión. Dous produtos que reparten rangos superpostos producen un enrutamento que parece correcto e non entrega nada. Manteña os grupos no mesmo documento que as rutas, para que un cambio nun sexa visible fronte ao outro.

Conservar a orixe ou reescribila

Conservar o enderezo de orixe do cliente mantén a visibilidade por usuario: os rexistros, as cotas e as regras da devasa poden distinguir un usuario doutro. O prezo é que a LAN de destino necesita unha ruta de retorno cara á pasarela, e alguén ten que mantela. Reescribir a orixe con NAT elimina ese requisito e elimina a visibilidade con el. Escolla a conciencia e anote que información oculta a reescritura.

O acceso á rede privada, a saída a internet e as conexións que rematan na propia pasarela son tres camiños distintos. Non todos necesitan o mesmo trato.

Describir o fluxo nunha frase

Unha frase debería describir o deseño: que clientes admite este servizo, que recursos concede esa política de reenvío e como o camiño de volta completa o fluxo. Se a frase necesita unha segunda capa de NAT para ser certa, adoita ser sinal de que as pezas anteriores non estaban resoltas. O host tamén é unha fronteira compartida de fallo e de confianza, así que un cambio de enrutamento pode afectar tanto o acceso dos usuarios como a administración. Manteña un camiño de recuperación independente para esta última.

Manteña un inventario de roles xunto á configuración: que produto pecha, cal reenvía, cal traduce e quen pode cambiar cada un. Ese é a lista que fai revisable o seguinte cambio.

Cando a frase se volve confusa, engadir outra capa de tradución raramente a aclara. Quitar unha adoita facelo.