Quen responde realmente no enderezo dedicado da VPN?

Un enderezo que queda sen usar na asignación da organización non é un oínte, e engadilo a un devasado non crea ningún. Algo ten que terminar IKE nese enderezo, e o mecanismo cambia segundo se a pasarela posúe o enderezo ou se un dispositivo augas arriba o traduce. A ruta do paquete é o que distingue os dous casos, e decide que función da plataforma precisa antes de que alguén abra unha solicitude de cambio. Modele primeiro a ruta e logo escolla.

A ruta do paquete detrás do enderezo

Un par envía IKE ao enderezo que recibiu, por UDP 500 ou por UDP 4500 cando hai travesía de NAT. O dispositivo que teña ese enderezo na ruta ou ben recibe o datagrama localmente e responde, ou ben o reenvía a outro lugar. Esas son as dúas únicas posibilidades, e todo o demais neste artigo depende de cal sexa certa.

Recibir localmente significa que existe un socket nese dispositivo, vinculado a ese enderezo. Reenviar significa que o datagrama se reescribe e se envía a outro extremo, que entón ten o socket. Unha regra de devasado que permite UDP 500 non lle di nada sobre cal das dúas cousas ocorre.

Escriba o rexistro antes de tocar nada: o enderezo co que contactan os pares, como o entrega a rede augas arriba, a interface local ou o extremo lóxico que o recibe, e o proceso que responde a IKE. Catro liñas, e cada unha pódese comprobar. Cando unha delas é descoñecida, ese descoñecemento é o traballo de deseño e non un detalle de implementación por resolver despois. Enchilas tras aprobar a solicitude de cambio é como unha regra de tradución acaba no dispositivo equivocado.

Modelo A: a pasarela posúe o enderezo

No primeiro modelo a pasarela ten o enderezo ela mesma, xa sexa como enderezo secundario nunha interface existente, como enderezo nunha interface dedicada ou como loopback que a plataforma admite como extremo de túnel. Son tres funcións distintas con tres rutas de configuración distintas, e unha plataforma que admite unha pode non admitir as demais.

Confirme que a plataforma e a versión admiten exactamente esa disposición antes de deseñar arredor dela. Un bloque encamiñado, un enderezo adicional nunha interface e un extremo loopback non son intercambiables, e a documentación dunha versión non promete que a seguinte se comporte igual.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

O socket á escoita é a proba. Se nada está vinculado ao enderezo, a pasarela non é o terminador diga o que diga a táboa de rutas, e unha captura de paquetes mostrará os datagramas chegando sen nada que os responda.

Non poña unha segunda interface nunha subrede que xa existe noutro lugar da topoloxía e supoña que a plataforma o resolverá. As subredes de interface solapadas producen unha selección de orixe ambigua e, en moitas plataformas, unha negativa a configurar de todo.

Modelo B: un dispositivo augas arriba tradúceo

No segundo modelo un devasado augas arriba ten o enderezo dedicado e reenvía o tráfico a outra pasarela VPN. Iso é unha tradución de destino con ruta de retorno, e é un deseño perfectamente válido sempre que se documente como tal.

O que non é, é proba de que o dispositivo augas arriba adquirise un socket VPN local. A tradución reenvía paquetes; non converte a caixa superior nun respondedor IKE. Se se elimina a regra augas arriba ou se rompe a súa ruta de retorno, a VPN detense aínda que a pasarela estea sá e os seus propios oíntes intactos.

Rexistre ambos os enderezos: o que contactan os pares e o que a pasarela ve realmente. Despois rexistre o transporte e a ruta de retorno, porque unha tradución que funciona para UDP 500 pero non para ESP encapsulado conectarase e despois non poderá transportar tráfico, o cal é un fallo confuso de depurar máis adiante.

A identidade non é o enderezo exterior

IPsec separa o extremo do túnel do tráfico que protexe, e a arquitectura mantén esas decisións en lugares distintos. Cambiar o enderezo co que contactan os pares non cambia automaticamente que prefixos internos se permiten, que rutas se instalan nin a que recursos pode chegar a sesión.

A identidade autenticada é de novo separada. IKEv2 leva unha carga de identidade e un intercambio de autenticación que non necesitan coincidir co enderezo exterior do paquete, e precisamente por iso un deseño traducido aínda pode autenticarse correctamente.

Esa independencia é útil e tamén unha trampa. Dous nomes DNS que resolven a un oínte corrente non seleccionan backends VPN distintos, e un certificado que nomea unha identidade non satisfará un par que espera outra. Confirme que valida o par antes de supor que o enderezo por si só o decide.

Acepte o deseño observando unha conexión

Inspeccione onde se entrega realmente unha conexión autorizada nova, que identidade responde e que fluxo privado se permite despois. Tres observacións, tres capas distintas, e unha consulta pública correcta do enderezo non proba ningunha delas.

Conserve tamén o caso negativo: un par que non debería aceptarse, ou un prefixo interno que non debería ser alcanzable, verificado tras o cambio. O rexistro que escribiu ao principio é o que fai posible esa proba sen reconstruír o deseño de memoria.

O sentido de todo isto é permitir que o propietario da rede elixa un método de asignación admitido en lugar de fiarse dunha afirmación xeral sobre o que cada devasado pode facer cun enderezo extra. Esa afirmación é exactamente onde estes deseños fallan, porque soa plausible en todas as plataformas e en xeral non é certa en ningunha. O rexistro de catro liñas resólveo para a súa plataforma en dez minutos.