Clientes descendentes detrás dun VPN superior: ruta ou NAT?

Unha pasarela executa WireGuard para os teus propios dispositivos e un cliente OpenVPN cara á rede doutra persoa. O reenvío entre as dúas interfaces internas funciona, e é fácil concluír que a subrede descendente xa forma parte do servizo superior. Non o é. Unha ruta que o cliente extrae dille á túa pasarela onde enviar as peticións; non di nada sobre como a rede remota devolve o tráfico a dispositivos dos que nunca oíu falar. Escolle un modelo de retorno que o servizo superior admita de verdade antes de engadir unha soa regra.

Decide o modelo de retorno antes de tocar o encamiñamento

Neste percorrido, os clientes descendentes usan 10.90.0.0/24, o enderezo do túnel superior asignado á pasarela é 10.80.0.6, e o recurso remoto aprobado é 172.20.0.30. Dous modelos encaixan nesa forma: conservar a orixe descendente e conseguir que o lado remoto a encamiñe, ou traducir a orixe ao enderezo do túnel da propia pasarela. Todo o posterior a esta decisión é mecánico, e a decisión en si necesita o propietario do servizo. Unha das filas de arriba é un acordo de encamiñamento co lado remoto; a outra é un cambio de política local que podes facer só. Confundir as dúas é o que converte un cambio de dez minutos nunha negociación.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Escolle unha fila e comprométete con ela. As filas son alternativas, non pasos, e mesturalas produce un deseño que ninguén pode explicar na revisión.

Conservación da orixe con encamiñamento

O lado remoto recibe unha petición dun enderezo descendente, así que necesita unha ruta admitida e a propiedade do peer para esa subrede, ademais de autorización para aceptala. Son axustes remotos, e ningunha ruta local de Linux os crea. Pídeos de forma explícita e por escrito, co prefixo e o peer do túnel que a transportará, e espera que a resposta dependa de se o servizo admite ou non arranxos de sitio a sitio.

Se a resposta é si, a configuración local é pequena: reenvío activado, os allowed-ips do peer de WireGuard que cobren o rango descendente, e unha política de devasas que permite o cruzamento en ambos os sentidos.

Tradución de orixe deliberada

Se o servizo só devolve o tráfico ao enderezo do cliente conectado, traduce a orixe a ese enderezo á saída e conserva o estado de conntrack que a invirte para as respostas. Limita a regra ás orixes descendentes previstas, aos destinos remotos previstos e á interface superior. Unha regra que traduce todo o que sae de cada interface é unha política moito maior que este requisito, e sorprenderate máis adiante.

IPv6 necesita o seu propio deseño; copiar unha liña de masquerade de IPv4 non é unha arquitectura. Proba a ruta traducida cunha conexión nova en lugar dunha na caché.

A ruta de datos local aínda ten que funcionar

A tradución non elimina o traballo local: a pasarela segue necesitando unha ruta para os destinos descendentes, a propiedade correcta da orixe do peer de WireGuard, o reenvío activado e unha política de devasas estreita entre interfaces. Unha petición xerada na propia pasarela non exerce ningún deses permisos, e por iso as probas locais na pasarela pasan e os dispositivos descendentes seguen fallando.

Proba desde un dispositivo descendente real, non desde a pasarela. O enderezo de orixe é todo o sentido do exercicio.

Unha orixe significa unha identidade de sesión

O servizo remoto ve a sesión autenticada da pasarela e o seu enderezo traducido, non unha autenticación independente para cada dispositivo descendente. Mantén explícitos os permisos por dispositivo e as identidades de aplicación, e confirma co propietario do servizo que unha pasarela que actúa por varios dispositivos está permitida. A tradución non é unha forma de saltar un requisito de alta por dispositivo; se o servizo esixe que cada dispositivo se dea de alta, usa ese modelo ou negocia un arranxo de sitio a sitio.

Escribe esa confirmación no runbook xunto á regra, porque o seguinte revisor preguntará se o deseño foi aprobado ou só conveniente.

Define o estado desconectado e despois proba tres peticións

Decide que ocorre cando cae o túnel superior. O tráfico remoto autorizado non debería seguir en silencio un respaldo WAN ordinario onde iso está prohibido, así que a política de devasas que permite o cruzamento tamén debe fallar pechada. Despois proba tres casos desde un dispositivo descendente real: unha petición permitida que funciona, unha petición non permitida que falla, e un fallo superior que detén a permitida.

Rexistra a reversión nunha liña por regra, para que o cambio poida desfacerse sen reconstruír a intención.