Nå et fjernt /24 gennem en tunnel: NETMAP, DNAT eller rute?
Kortlæg et helt præfiks med NETMAP, tilføj DNAT-regler pr. vært eller rut den rigtige range, og afgør ud fra, hvad den fjerne side skal se, og hvem der må starte trafik.
Du kan nå et undernet bag et tunnelendepunkt på tre måder, og et minut med fakta udelukker normalt to. Fakta er, om serverne derude skal skelne mellem brugere, om nogen derude nogensinde ringer mod din range, og hvem der må redigere routeren i den fjerne ende. Svar på de tre, og designet vælger sig selv. Resten forudsætter, at du driver endepunktet og må redigere dets firewall.
Tre muligheder, og hvad hver af dem faktisk ændrer
Præfiksmapning, DNAT per vært og et rutet præfiks flytter alle pakker mellem de samme to ranges, men de ændrer forskellige ting. Mapning opfinder en alias-range og omskriver adresser aritmetisk undervejs. Regler per vært omskriver også, bortset fra at hver destination navngives manuelt. Et rutet præfiks omskriver intet: pakkerne beholder de rigtige adresser, og begge ender er enige om, hvor de adresser bor.
| 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 |
Begynd udelukkelsen på den fjerne side, hvor begrænsningerne er sværest at ændre. Hvis en server derude skriver klientadresser i logfiler, tjekker dem mod en allowlist eller giver dem videre til et andet system, ødelægger oversættelsen af kilden dens eneste identifikator. Hvis den fjerne side også skal ringe ind, er oversættelse helt udelukket, fordi ingen derude ved, at aliaset findes. Kun når den fjerne side blot besvarer anmodninger, bliver de billigere muligheder sikre.
Præfikspar, og hvorfor størrelserne skal passe
NETMAP er et nat-tabelmål, der arbejder på et par præfikser af samme længde. Det har ingen tabel per adresse indeni: det fjerner præfikset, beholder værtsbittene og sætter dem på det nye præfiks, og derfor mapper et /24 til et /24 og aldrig til et /25. Positionen bestemmer retningen: et destinationsmatch i PREROUTING omskriver, hvor en pakke er på vej hen, og et kildematch i POSTROUTING omskriver, hvor den kom fra.
En vært på 192.168.2.17 vises for dine klienter som 10.50.1.17, og den sidste oktet er ikke dekorativ — det er det samme tal på begge sider. Tilføj en vært på 192.168.2.40 i morgen, og dens alias er 10.50.1.40, uden nogen regel at redigere.
Klienter har stadig brug for en rute til alias-rangen, der peger på din boks, medmindre aliaset ligger i et undernet, de allerede når. Gatewayen har ikke brug for en rute til aliaset, fordi destinationsoversættelse kører i PREROUTING, før ruteopslaget. Videresendelse skal også være slået til, ellers dropper kernen pakken efter omskrivningen. De tre kommandoer nedenfor er hele opsætningen på en Debian-agtig gateway med klienter på br0, aliaset på 10.50.1.0/24 og tunnelen på 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 MASQUERADESvaret skal selv finde vejen tilbage
At omskrive destinationen bestemmer kun, hvor en pakke bliver leveret. Serveren på den fjerne side skal stadig svare på en adresse, den kan nå, og der er to måder at arrangere det på. Oversæt kilden, så svar vender tilbage til din boks, eller lad kilden være og giv den fjerne side en rute til klient-rangen.
Maskering på vejen ud er den kortere vej: én regel i POSTROUTING, og den fjerne side ser din tunneladresse, så den har ikke brug for sin egen rute. Prisen er, at alle brugere smelter sammen i én adresse, og logfiler per bruger holder op med at betyde noget. At lade kilden være intakt bevarer den information, men så skal det fjerne sted sende svar for klient-rangen tilbage gennem tunnelen. På en OpenVPN server er det en pushet push "route 10.50.9.0 255.255.255.0", plus en linje route 192.168.2.0 255.255.255.0.
Den dyre fejl er at gøre halvdelen af hver. Hvis du maskerer noget trafik, mens den fjerne side også bærer en returrute for anden trafik, ankommer svar på et interface, hvor forbindelsessporingsposten aldrig blev set. Klienten rapporterer timeout for en anmodning, som serveren loggede som besvaret. Begge retninger af en strøm skal krydse den samme netfilter-instans: én gateway der oversætter, ikke to firewalls i serie.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLæs posten i begge retninger: den oprindelige tuple beholder dit alias som destination, mens svar-tuplen bærer den rigtige adresse. Hvis svar-tuplen mangler, er returvejen problemet snarere end reglen. Hvis PREROUTING-tællerne aldrig flyttede sig, nåede pakken aldrig den hook.
Kollisioner og det opslag, der kører først
To forskellige ranges kan kollidere, og begge fejl ser ud som en brudt tunnel snarere end en dårlig regel. Det alias, du opfinder, skal være ubrugt hele vejen, og den rigtige fjerne range må ikke allerede findes på dit netværk. En dublet giver periodisk trafik til den forkerte vært, hvilket er sværere at diagnosticere end en afvist forbindelse. Spørg rutetabellen, før du tilføjer en regel.
På gatewayen bør ip route get 192.168.2.17 navngive tunnel-enheden; en lokal bridge betyder, at den fjerne range er skygget, og ingen nat-regel reparerer det. Hvis dit eget netværk allerede bruger 192.168.2.0/24, omnummerér det fjerne sted i stedet for at stable en mapning oven på kollisionen.
Test fra en rigtig klient, og behold det så
Test fra en maskine, der faktisk skal bruge aliaset, ikke fra gatewayen, fordi lokalt genereret trafik aldrig passerer PREROUTING på samme måde. Åbn en forbindelse til en aliaseret vært, og se tællerne og conntrack-posten dukke op sammen, luk den så, og bekræft, at posten forsvinder. En forældet post peger på en halvåben forbindelse, hvilket normalt betyder, at svaret aldrig kom tilbage.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17To eller tre vellykkede forbindelser beviser aritmetikken, men de siger intet om persistens eller om den næste ingeniør. Gem reglerne, hvor bootprocessen læser dem, hvilket på Debian og Ubuntu betyder iptables-save > /etc/iptables/rules.v4 med netfilter-persistent aktiveret. En mapning, der forsvinder ved genstart, er værre end ingen, fordi udfaldet kommer uden en nylig ændring at skylde på.
Skriv en note ved reglerne: alias-rangen, den rigtige range, grunden til parret og hvilken side der må initiere. Den note adskiller et design fra en bunke regler, som ingen tør slette. Den afgør også det senere spørgsmål, når det fjerne sted tilføjer en vært, og en adresse, som ingen har konfigureret, allerede svarer. Hvis noten siger, at den fjerne side har brug for en returrute, ved den næste person, at fjernelse af maskeringsreglen bryder forbindelsen. Dokumentation er billig her; at genopdage en NAT-afhængighed klokken tre om natten er ikke.