Arribar a una /24 remota per un túnel: NETMAP, DNAT o ruta?
Mapeu tot un prefix amb NETMAP, afegiu regles DNAT per host o encamineu el rang real, i decidiu segons què ha de veure el costat remot i qui pot iniciar el trànsit.
Podeu arribar a una subxarxa darrere d'un extrem de túnel de tres maneres, i un minut de recollida de fets normalment en descarta dues. Els fets són si els servidors d'allà han de distingir els usuaris, si algú d'allà trucarà mai cap al vostre rang i qui pot editar l'encaminador de l'extrem remot. Contesteu aquests tres i el disseny es tria sol. La resta assumeix que vosaltres gestioneu l'extrem i podeu editar-ne el tallafoc.
Tres opcions, i què canvia realment cadascuna
El mapatge de prefixos, el DNAT per host i un prefix encaminat mouen tots els paquets entre els mateixos dos rangs, però canvien coses diferents. El mapatge inventa un rang d'àlies i reescriu les adreces aritmèticament en ple vol. Les regles per host també reescriuen, tret que cada destinació es nomena a mà. Un prefix encaminat no reescriu res: els paquets conserven les adreces reals i tots dos extrems acorden on viuen aquestes adreces.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Comenceu l'eliminació pel costat remot, on les restriccions són més difícils de canviar. Si un servidor d'allà escriu les adreces dels clients als registres, les comprova contra una llista permesa o les lliura a un altre sistema, traduir la font destrueix el seu únic identificador. Si el costat remot també ha de trucar, la traducció queda descartada del tot, perquè allà ningú no sap que l'àlies existeix. Només quan el costat remot es limita a respondre peticions les opcions més barates són segures.
Parells de prefixos, i per què les mides han de coincidir
NETMAP és un objectiu de la taula nat que treballa sobre un parell de prefixos de la mateixa longitud. No té cap taula per adreça a dins: treu el prefix, conserva els bits d'host i els torna a enganxar al prefix nou, i per això una /24 es mapeja a una /24 i mai a una /25. La posició decideix la direcció: una coincidència de destinació a PREROUTING reescriu on va un paquet, i una coincidència de font a POSTROUTING reescriu d'on ve.
Un host a 192.168.2.17 apareix als vostres clients com a 10.50.1.17, i l'últim octet no és decoratiu — és el mateix número als dos costats. Afegiu demà un host a 192.168.2.40 i el seu àlies és 10.50.1.40, sense cap regla per editar.
Els clients encara necessiten una ruta per al rang d'àlies que apunti a la vostra caixa, tret que l'àlies caigui dins d'una subxarxa que ja abasten. La passarel·la no necessita cap ruta per a l'àlies, perquè la traducció de destinació s'executa a PREROUTING, abans de la cerca de ruta. L'encaminament també ha d'estar activat, o el nucli descarta el paquet després de la reescriptura. Les tres ordres següents són tota la configuració en una passarel·la a l'estil Debian amb els clients a br0, l'àlies a 10.50.1.0/24 i el túnel a 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 MASQUERADELa resposta ha de trobar el seu propi camí de tornada
Reescriure la destinació només decideix on es lliura un paquet. El servidor del costat remot encara ha de respondre a una adreça que pugui abastar, i hi ha dues maneres d'organitzar-ho. Traduïu la font perquè les respostes tornin a la vostra caixa, o deixeu la font tranquil·la i doneu al costat remot una ruta per al rang de clients.
L'emmascarament a la sortida és el camí més curt: una regla a POSTROUTING i el costat remot veu l'adreça del vostre túnel, així que no necessita cap ruta pròpia. El cost és que tots els usuaris s'ajunten en una sola adreça, i els registres per usuari deixen de significar res. Deixar la font intacta conserva aquesta informació, però llavors el lloc remot ha d'enviar les respostes del rang de clients de tornada pel túnel. En un OpenVPN servidor això és un push "route 10.50.9.0 255.255.255.0" enviat, més una línia route 192.168.2.0 255.255.255.0.
La fallada cara és fer la meitat de cada cosa. Si emmascareu part del trànsit mentre el costat remot també porta una ruta de tornada per a un altre trànsit, les respostes arriben en una interfície on l'entrada de seguiment de connexions no s'havia vist mai. El client informa d'un temps d'espera per a una petició que el servidor va registrar com a servida. Les dues direccions d'un flux han de creuar la mateixa instància de netfilter: una passarel·la que tradueix, no dos tallafocs en sèrie.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLlegiu l'entrada en tots dos sentits: la tupla original conserva el vostre àlies a la destinació, mentre que la tupla de resposta porta l'adreça real. Si la tupla de resposta falta, el problema és el camí de tornada i no la regla. Si els comptadors de PREROUTING no s'han mogut mai, el paquet no va arribar mai a aquest hook.
Col·lisions i la cerca que s'executa primer
Dos rangs diferents poden col·lidir i totes dues fallades semblen un túnel trencat i no una regla dolenta. L'àlies que inventeu ha d'estar sense usar al llarg de tot el camí, i el rang real del costat remot no ha d'existir ja a la vostra xarxa. Un duplicat produeix trànsit intermitent cap a l'host equivocat, que és més difícil de diagnosticar que una connexió rebutjada. Pregunteu a la taula d'encaminament abans d'afegir una regla.
A la passarel·la, ip route get 192.168.2.17 hauria de nomenar el dispositiu del túnel; un pont local vol dir que el rang remot queda amagat i cap regla nat ho repararà. Si la vostra xarxa ja fa servir 192.168.2.0/24, renumereu el lloc remot en lloc d'apilar un mapatge sobre la col·lisió.
Provar-ho des d'un client real, i després conservar-ho
Proveu-ho des d'una màquina que realment farà servir l'àlies, no des de la passarel·la, perquè el trànsit generat localment no travessa mai PREROUTING de la mateixa manera. Obriu una connexió a un host amb àlies i observeu com els comptadors i l'entrada de conntrack apareixen junts, després tanqueu-la i confirmeu que l'entrada se'n va. Una entrada obsoleta assenyala una connexió mig oberta, cosa que normalment vol dir que la resposta no va tornar mai.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Dues o tres connexions correctes demostren l'aritmètica, però no diuen res sobre la persistència ni sobre el proper enginyer. Deseu les regles on les llegeix el procés d'arrencada, que a Debian i Ubuntu vol dir iptables-save > /etc/iptables/rules.v4 amb netfilter-persistent activat. Un mapatge que desapareix en reiniciar és pitjor que cap, perquè l'apagada arriba sense cap canvi recent a qui culpar.
Deixeu una nota al costat de les regles: el rang d'àlies, el rang real, la raó del parell i quin costat pot iniciar. Aquesta nota separa un disseny d'un munt de regles que ningú no gosa esborrar. També resol la pregunta posterior, quan el lloc remot afegeix un host i una adreça que ningú no ha configurat ja respon. Si la nota diu que el costat remot necessita una ruta de tornada, la propera persona sap que treure la regla d'emmascarament trenca la connectivitat. La documentació aquí és barata; redescobrir una dependència de NAT a les tres de la matinada no ho és.