A mesma subrede nos dous extremos: asignade a LAN remota a un rango libre
A asignación de enderezos no lado do cliente pode presentar unha LAN remota solapada baixo un rango libre, pero só algúns clientes a aplican e o camiño de volta debe existir de todos os xeitos.
A casa e a oficina usan ambas 192.168.1.0/24, así que unha petición a 192.168.1.1 ten dúas respostas posibles e o cliente escolle unha sen preguntar. Renumerar unha rede de oficina en funcionamento raramente é popular, e os enderezos do router adoitan estar incrustados en impresoras, cámaras e documentación. A asignación de enderezos no lado do cliente pode presentar a rede remota baixo un rango libre no seu lugar, e a parte de host pode seguir igual para que 192.168.1.20 apareza como 10.203.41.20. A trampa é que só algúns clientes a implementan e non fai nada polo camiño de volta.
Dúas visións do mesmo host
A asignación conserva a parte de host e cambia só a parte de rede. A mesma máquina responde entón en dous enderezos segundo onde esteades. Escribir ambas columnas antes de configurar nada evita unha mala lectura posterior dos rexistros e das regras da devasa.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
Os dispositivos locais da casa conservan os seus propios enderezos 192.168.1.x, e ese é o obxectivo do exercicio. A impresora da sala contigua segue sendo accesible mentres a oficina aparece baixo un rango que non entra en conflito.
A orde dos argumentos é todo o truco
A opción toma unha dirección, unha rede e máscara, e un alias: a primeira rede é o que ve o cliente, o alias é o que ve o servidor. Para os recursos que viven detrás da pasarela remota, a dirección é a forma de destino. Inverter as dúas redes porque o último argumento se chama alias é o erro que produce un túnel que se conecta e non asigna nada.
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"A ruta é o que envía os paquetes do cliente para o novo rango ao túnel; a tradución reescribe o destino durante o paso. Unha resposta de 192.168.1.20 reescríbese de volta a 10.203.41.20 para que o socket do cliente siga sendo coherente. Un só host funciona igual cunha máscara de lonxitude completa, sempre que a ruta e a asignación describan o mesmo enderezo.
Isto é unha asignación de enderezos, non unha asignación de portos. Dous servizos nun mesmo host non se poden separar con ela, e un protocolo que incrusta enderezos IP dentro da súa carga útil seguirá vendo os reais.
A asignación non crea un camiño de volta
A tradución ocorre no cliente, así que o servidor aínda ten que encamiñar as respostas ao túnel e a súa devasa aínda ten que permitilas. Se a pasarela remota non sabe como chegar á subrede do túnel, a petición chega e a resposta sae pola porta equivocada; a asignación só fai que o fallo pareza un problema do cliente.
As regras do lado do servidor deberían describir os enderezos que existen no servidor despois da tradución, non o rango visible para o cliente. Copiar o alias nunha regra de permiso malgasta unha tarde, porque ningún paquete dese lado o leva.
Escollede un rango de alias que non entre en conflito con nada máis que o cliente encamiñe: outra VPN, unha rede de contedores, unha segunda oficina. Un conflito aquí reintroduce a ambigüidade orixinal baixo un número distinto e é máis difícil de ver porque os enderezos parecen descoñecidos.
Os nomes e as cargas útiles sobreviven á tradución
Un nome de host que se resolve no 192.168.1.20 real envía o navegador ao dispositivo local en lugar do remoto, diga o que diga a táboa de encamiñamento. A resposta do DNS privado ten que apuntar ao rango visible para o cliente, mentres que o certificado TLS segue levando o nome que a aplicación espera. Probade co nome en lugar de co enderezo, porque o enderezo pode funcionar mentres o nome se resolve en silencio na dirección equivocada. Cando a pasarela remota tamén serve esa zona, os seus propios rexistros tamén necesitan o rango visible para o cliente.
As redireccións, as URL incrustadas e as aplicacións que entregan o seu propio enderezo nunha carga útil poden romper de formas que ningunha asignación de paquetes pode reparar. Tratádeas como un problema de aplicación e dimensionade o esforzo en consecuencia antes de prometer que renumerar non é necesario.
Tres comprobacións antes de comprometerse
Primeiro, confirmade a implementación do cliente. Community OpenVPN admite esta opción; a base de código de OpenVPN 3 inclúea entre as funcións non admitidas, así que un perfil empurrado a un cliente de estilo Connect pode simplemente ignoralo. Unha directiva que se acepta e nunca se aplica é peor que un erro, porque o túnel parece saudable.
Segundo, verificade a ruta e a tradución por separado cunha ventá de diagnóstico breve a alta verbosidade, e despois probade o servizo real en lugar dun ping. Terceiro, confirmade que o router local e o recurso remoto seguen sendo distinguibles desde o cliente, xa que ese era o obxectivo orixinal.
Se o cliente non pode facer a tradución, pedide axuda ao lado da pasarela ou aceptade unha renumeración. Engadir máis rutas para o mesmo enderezo non é un deseño.