NAT no servidor VPN ou no router? As dúas opcións poden funcionar

Marcar unha conexión como ruta predeterminada nun portátil é o paso que todo o mundo lembra, e é xusto o que non cambia nada na pasarela. Agora o cliente envía as solicitudes de Internet ao túnel; se saen do edificio depende do reenvío, dun punto de tradución e dun camiño de volta que chegue ao enderezo privado do cliente. Dúas disposicións poden fornecer as tres cousas, colocan o traballo en lugares distintos e ambas fallan do mesmo xeito silencioso cando ninguén se fai cargo da dirección da resposta. Escoller entre elas é unha cuestión de quen debe ver o conxunto de clientes.

O mito: unha ruta de cliente constrúe a saída

O tunneling forzado é unha política do lado do cliente: decide que o tráfico vai ao adaptador VPN en lugar do físico. A documentación de enrutamento VPN de Microsoft describe ese comportamento de separación e de forzado, e é unha afirmación sobre a táboa de rutas do cliente, non sobre as regras de reenvío do servidor. Desde o punto de vista do cliente, o túnel é onde vive Internet; desde o punto de vista da pasarela, un paquete chegou desde un enderezo que ninguén augas arriba oíu nunca. Ningunha das dúas partes está mal configurada por si soa, e por iso o fallo parece un servidor roto para a persoa que está no portátil.

Ese desaxuste é todo o problema que resolve o resto deste artigo. Algo ten que facer que o enderezo privado do cliente sexa retornable, e a elección é onde.

Debuxe primeiro o camiño de volta

Escriba o camiño con enderezos reais antes de tocar ningún axuste, e marque nel os dous puntos de tradución candidatos. Este laboratorio usa un conxunto VPN de 10.70.0.0/24 cun cliente en 10.70.0.37, un enderezo LAN do servidor de 172.16.40.10, un router en 172.16.40.1 e unha saída pública de 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

O servidor que xa navega por Internet só demostra o seu propio camiño. Un paquete reenviado no nome dun cliente é unha decisión distinta, tomada pola política de reenvío na mesma máquina, e é a que adoita faltar. Marcar os tres puntos de decisión no diagrama mantén a conversa sobre un deles á vez.

Opción A: traducir no servidor VPN

Aquí o servidor traduce a orixe do cliente ao seu propio enderezo LAN antes de entregar o paquete ao router, e o router aplica a súa tradución habitual na saída. Na resposta, a asignación do router restaura o enderezo do servidor e a asignación do servidor restaura o enderezo do cliente. Dúas traducións con estado en serie son normais e viables, sempre que ambas queden rexistradas; o router nunca necesita unha ruta ao conxunto, que é o atractivo desta disposición.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Use estas lecturas para ver que ten xa o servidor en lugar de supor que hai un NAT. Unha regra de masquerade de Linux copiada dun blog non é unha configuración de Windows, e un permiso no cortafuegos do host para o escoitador VPN non é a mesma política que o permiso para reenviar a solicitude dun cliente máis alá. Confirme o papel de reenvío do servidor desde a súa propia superficie de administración, e despois mire a tradución por separado, porque as dúas cousas adoitan habilitarse desde partes distintas dun despregue.

Opción B: levar o conxunto ao router

Na segunda disposición o servidor reenvía o enderezo de orixe real do cliente, e o router tradúceo. Iso mantén o conxunto de clientes visible na beira, o que axuda se o router é onde viven a política de tráfico, o rexistro ou a inspección. Tamén significa que o router necesita unha ruta de volta para 10.70.0.0/24 que apunte a 172.16.40.10, ademais dunha política de Internet que inclúa realmente ese prefixo; unha regra escrita para a subrede LAN non se estende en silencio ao conxunto.

Escolla esta opción cando o dispositivo de beira sexa o responsable previsto da política e poida aceptar outro prefixo nas súas táboas de enrutamento e tradución. Escolla a tradución do lado do servidor cando o conxunto deba quedar invisible augas arriba e o router non o administre o mesmo equipo. Ningunha das dúas opcións se deduce de ningunha casilla do cliente, e ningunha é máis segura en xeral; colocan a visibilidade e o mantemento en lugares distintos.

Faga explícitos o DNS, o IPv6 e a aceptación

A tradución de enderezos non arranxa a resolución de nomes. O cliente pode usar un resolutor entregado co perfil VPN, un resolutor privado para espazos de nomes concretos ou un público aprobado, e un resolutor inalcanzable baixo esa política seguirá fallando despois de que o enrutamento funcione. Probe un nome e un enderezo por separado para que os dous fallos nunca se fundan nun único informe.

O IPv6 necesita o seu propio parágrafo no deseño. Unha tradución IPv4 que funcione non di nada sobre se os clientes IPv6 teñen ruta, unha fonte pública válida ou unha política que os bloquee cando o túnel cae. Deixar iso sen dicir significa que a metade dos clientes evita a pasarela en silencio mentres a outra metade funciona.

Para a aceptación, siga unha solicitude de cliente permitida e a súa resposta polas dúas fronteiras, e anote que enderezo debería ver cada fronteira nese momento. Ese rexistro é o que converte o seguinte cambio de conxunto nunha edición de cinco minutos en lugar dunha discusión sobre quen posúe a ruta de volta que falta. Garde o rexistro co perfil do cliente en lugar de nun tícket, xa que o perfil é o que o seguinte enxeñeiro atopará primeiro.