Chegar a unha /24 remota por un túnel: NETMAP, DNAT ou ruta?

Pódese chegar a unha subrede detrás dun extremo de túnel de tres maneiras, e un minuto de recoller feitos adoita descartar dúas. Os feitos son se os servidores de alí deben distinguir os usuarios, se alguén de alí marcará algunha vez cara ao seu rango, e quen pode editar o router do extremo remoto. Responda a eses tres e o deseño escóllese só. O resto supón que vostede opera o extremo e pode editar o seu devasado.

Tres opcións, e que cambia realmente cada unha

A asignación de prefixos, o DNAT por host e un prefixo encamiñado moven todos os paquetes entre os mesmos dous rangos, pero cambian cousas distintas. A asignación inventa un rango alias e reescribe enderezos aritmeticamente en voo. As regras por host tamén reescriben, agás que cada destino se nomea a man. Un prefixo encamiñado non reescribe nada: os paquetes conservan os enderezos reais e ambos os extremos acordan onde viven eses enderezos.

Comece a eliminación polo lado remoto, onde as restricións son máis difíciles de cambiar. Se un servidor de alí escribe os enderezos dos clientes en rexistros, compróbaos contra unha lista de permitidos ou entrégaos a outro sistema, traducir a orixe destrúe o seu único identificador. Se o lado remoto tamén debe marcar, a tradución queda descartada por completo, porque alí ninguén sabe que o alias existe. Só cando o lado remoto se limita a responder peticións as opcións máis baratas son seguras.

Pares de prefixos, e por que os tamaños deben coincidir

NETMAP é un obxectivo da táboa nat que traballa sobre un par de prefixos de idéntica lonxitude. Non ten unha táboa por enderezo dentro: quita o prefixo, conserva os bits de host e volve enganchalos ao prefixo novo, por iso unha /24 se asigna a unha /24 e nunca a unha /25. A posición decide a dirección: unha coincidencia de destino en PREROUTING reescribe cara a onde vai un paquete, e unha de orixe en POSTROUTING reescribe de onde veu.

Un host en 192.168.2.17 aparece ante os seus clientes como 10.50.1.17, e o último octeto non é decorativo: é o mesmo número en ambos os lados. Engada mañá un host en 192.168.2.40 e o seu alias será 10.50.1.40, sen ningunha regra que editar.

Os clientes seguen necesitando unha ruta para o rango alias que apunte á súa máquina, agás que o alias caia dentro dunha subrede que xa alcanzan. A pasarela non necesita ruta para o alias, porque a tradución de destino se executa en PREROUTING, antes da busca de ruta. O reenvío tamén debe estar activo, ou o núcleo descarta o paquete tras a reescritura. Os tres comandos de abaixo son toda a configuración nunha pasarela ao estilo Debian cos clientes en br0, o alias en 10.50.1.0/24 e o túnel en tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

A resposta ten que atopar o seu propio camiño de volta

Reescribir o destino só decide onde se entrega un paquete. O servidor do lado remoto aínda debe responder a un enderezo que poida alcanzar, e hai dúas formas de organizalo. Traduza a orixe para que as respostas volvan á súa máquina, ou deixe a orixe intacta e dea ao lado remoto unha ruta para o rango de clientes.

A máscara á saída é o camiño máis curto: unha regra en POSTROUTING e o lado remoto ve o enderezo do seu túnel, así que non necesita ruta propia. O custo é que todos os usuarios se funden nunha soa dirección, e os rexistros por usuario deixan de significar nada. Deixar a orixe intacta conserva esa información, pero entón o sitio remoto debe enviar as respostas do rango de clientes de volta polo túnel. Nun OpenVPN servidor iso é un push "route 10.50.9.0 255.255.255.0" enviado, máis unha liña route 192.168.2.0 255.255.255.0.

O fallo caro é facer a metade de cada cousa. Se enmascara parte do tráfico mentres o lado remoto tamén leva unha ruta de volta para outro tráfico, as respostas chegan por unha interface onde a entrada de seguimento de conexións nunca se viu. O cliente informa dun tempo de espera para unha petición que o servidor rexistrou como atendida. Ambas as direccións dun fluxo deben cruzar a mesma instancia de netfilter: unha pasarela que traduce, non dous devasados en serie.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Lea a entrada en ambos os sentidos: a tupla orixinal conserva o seu alias no destino, mentres que a tupla de resposta leva o enderezo real. Se falta a tupla de resposta, o problema é o camiño de volta e non a regra. Se os contadores de PREROUTING nunca se moveron, o paquete nunca chegou a ese gancho.

Colisións e a busca que se executa primeiro

Dous rangos distintos poden colidir e ambos os fallos parecen un túnel roto e non unha regra mala. O alias que invente debe estar sen usar en todo o camiño, e o rango real do lado remoto non debe existir xa na súa rede. Un duplicado produce tráfico intermitente cara ao host equivocado, que é máis difícil de diagnosticar que unha conexión rexeitada. Pregunte á táboa de rutas antes de engadir unha regra.

Na pasarela, ip route get 192.168.2.17 debería nomear o dispositivo do túnel; unha ponte local significa que o rango remoto está oculto e ningunha regra nat o reparará. Se a súa propia rede xa usa 192.168.2.0/24, renumere o sitio remoto en lugar de apilar unha asignación sobre a colisión.

Probalo desde un cliente real e despois conservalo

Probe desde unha máquina que realmente vaia usar o alias, non desde a pasarela, porque o tráfico xerado localmente nunca atravesa PREROUTING do mesmo xeito. Abra unha conexión a un host con alias e observe aparecer xuntos os contadores e a entrada de conntrack, logo péchea e confirme que a entrada desaparece. Unha entrada obsoleta apunta a unha conexión medio aberta, o que adoita significar que a resposta nunca volveu.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Dúas ou tres conexións correctas demostran a aritmética, pero non din nada sobre a persistencia nin sobre o seguinte enxeñeiro. Garde as regras onde as le o proceso de arranque, que en Debian e Ubuntu significa iptables-save > /etc/iptables/rules.v4 con netfilter-persistent activado. Unha asignación que desaparece ao reiniciar é peor que ningunha, porque a caída chega sen ningún cambio recente ao que culpar.

Deixe unha nota xunto ás regras: o rango alias, o rango real, a razón do par e que lado pode iniciar. Esa nota separa un deseño dunha morea de regras que ninguén se atreve a borrar. Tamén resolve a pregunta posterior, cando o sitio remoto engade un host e un enderezo que ninguén configurou xa responde. Se a nota di que o lado remoto necesita unha ruta de volta, a seguinte persoa sabe que quitar a regra de máscara rompe a conectividade. A documentación aquí é barata; redescubrir unha dependencia de NAT ás tres da mañá non o é.