Nå eit eksternt /24 gjennom ein tunnel: NETMAP, DNAT eller rute?
Kartlegg eit heilt prefiks med NETMAP, legg til DNAT-reglar per vert eller rut det verkelege området, og avgjer ut frå kva den andre sida må sjå og kven som kan starte trafikk.
Du kan nå eit subnett bak eit tunnelendepunkt på tre måtar, og eitt minutt med faktainnsamling diskvalifiserer vanlegvis to. Faktaa er om tenarane der borte må skilje brukarar, om nokon der nokon gong vil ringje mot området ditt, og kven som kan redigere rutaren i den andre enden. Svar på dei tre, og designet vel seg sjølv. Resten føreset at du driv endepunktet og kan redigere brannmuren der.
Tre alternativ, og kva kvart av dei faktisk endrar
Prefikskartlegging, DNAT per vert og eit ruta prefiks flyttar alle pakkar mellom dei same to områda, men dei endrar ulike ting. Kartlegging finn opp eit aliasområde og skriv om adresser aritmetisk undervegs. Reglar per vert skriv også om, bortsett frå at kvar destinasjon blir namngitt for hand. Eit ruta prefiks skriv om ingenting: pakkane held på dei verkelege adressene, og begge endar er samde om kvar desse adressene bur.
| 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 |
Start elimineringa på den andre sida, der avgrensingane er vanskelegast å endre. Viss ein tenar der skriv klientadresser til loggar, sjekkar dei mot ei tillatingsliste eller gir dei vidare til eit anna system, øydelegg omsetjing av kjelda den einaste identifikatoren. Viss den andre sida også må ringje inn, er omsetjing heilt utelukka, fordi ingen der veit at aliaset finst. Berre når den andre sida berre svarar på førespurnader, blir dei billegare alternativa trygge.
Prefikspar, og kvifor storleikane må stemme
NETMAP er eit mål i nat-tabellen som arbeider på eit par prefiks av identisk lengd. Det har ingen tabell per adresse inni: det fjernar prefikset, held på vertsbitane og festar dei til det nye prefikset, og difor blir eit /24 kartlagt til eit /24 og aldri til eit /25. Posisjonen avgjer retninga: eit destinasjonsmatch i PREROUTING skriv om kvar ein pakke skal, og eit kjeldematch i POSTROUTING skriv om kvar han kom frå.
Ein vert på 192.168.2.17 viser seg for klientane dine som 10.50.1.17, og den siste oktetten er ikkje dekorasjon — det er same talet på begge sider. Legg til ein vert på 192.168.2.40 i morgon, og aliaset hans er 10.50.1.40, utan reglar å redigere.
Klientane treng framleis ei rute for aliasområdet som peikar mot boksen din, med mindre aliaset fell innanfor eit subnett dei allereie når. Gatewayen treng inga rute for aliaset, fordi destinasjonsomsetjinga køyrer i PREROUTING, før ruteoppslaget. Videresending må også vere på, elles slepp kjernen pakka etter omskrivinga. Dei tre kommandoane nedanfor er heile oppsettet på ein Debian-liknande gateway med klientar 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 må finne vegen tilbake sjølv
Omskriving av destinasjonen avgjer berre kvar ei pakke blir levert. Tenaren på den andre sida må framleis svare på ei adresse han når, og det kan ordnast på to måtar. Omset kjelda slik at svara kjem tilbake til boksen din, eller lat kjelda vere og gi den andre sida ei rute for klientområdet.
Masquerading på veg ut er den kortare vegen: éin regel i POSTROUTING, og den andre sida ser tunneladressa di, så ho treng inga eiga rute. Prisen er at kvar brukar kollapsar til éi adresse, og loggar per brukar sluttar å bety noko. Å late kjelda vere intakt held på informasjonen, men då må det fjerne nettstaden sende svar for klientområdet tilbake gjennom tunnelen.OpenVPN tenar er det ein pusha push "route 10.50.9.0 255.255.255.0", pluss ei route 192.168.2.0 255.255.255.0 line.
Den dyre feilen er å gjere halvparten av kvar. Viss du maskerer noko trafikk medan den andre sida også har ei returrute for annan trafikk, kjem svara inn på eit grensesnitt der tilkoplingssporingsposten aldri vart sett. Klienten rapporterer tidsavbrot for ein førespurnad tenaren loggføyrte som betent. Begge retningar av ein flyt må krysse same netfilter-instans: éin gateway som omset, ikkje to brannmurar i serie.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLes posten i begge retningar: den opphavlege tuple held på aliaset ditt på destinasjonen, medan svar-tuplen ber den verkelege adressa. Viss svar-tuplen manglar, er problemet returvegen, ikkje regelen. Viss PREROUTING-teljarane aldri har flytta seg, nådde pakka aldri den kroken.
Kollisjonar og oppslaget som køyrer først
To ulike område kan kollidere, og begge feila ser ut som ein øydelagd tunnel snarare enn ein dårleg regel. Aliaset du finn opp må vere ubrukt langs heile vegen, og det verkelege området på den andre sida må ikkje allereie finnast på nettverket ditt. Ein duplikat gir avbroten trafikk til feil vert, som er vanskelegare å diagnostisere enn ei avvist tilkopling. Spør rutetabellen før du legg til ein regel.
På gatewayen, ip route get 192.168.2.17 skal namngi tunnel-eininga; ei lokal bru betyr at det fjerne området er skyggelagt og ingen nat-regel reparerer det. Viss nettverket ditt allereie brukar 192.168.2.0/24, omnummerer den fjerne nettstaden i staden for å stable ei kartlegging på kollisjonen.
Teste det frå ein verkeleg klient, og deretter halde på det
Test frå ein maskin som faktisk skal bruke aliaset, ikkje frå gatewayen, fordi lokalt generert trafikk aldri kryssar PREROUTING på same måte. Opne ei tilkopling til éin vert med alias og sjå teljarane og conntrack-posten dukke opp saman, lukk ho så og stadfest at posten forsvinn. Ein gamal post peikar på ei halvopen tilkopling, som vanlegvis betyr at svaret aldri kom tilbake.
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 vellukka tilkoplingar beviser aritmetikken, men dei seier ingenting om varigheit eller om neste ingeniør. Lagre reglane der oppstartsprosessen les dei, som på Debian og Ubuntu betyr iptables-save > /etc/iptables/rules.v4 med netfilter-persistent aktivert. Ei kartlegging som forsvinn ved omstart er verre enn inga, fordi avbrotet kjem utan ei nyleg endring å skylde på.
Legg igjen eit notat ved reglane: aliasområdet, det verkelege området, grunnen til paret og kva side som kan initiere. Notatet skil eit design frå ein haug med reglar ingen tør å slette. Det avgjer også det seinare spørsmålet, når den fjerne nettstaden legg til ein vert og ei adresse ingen konfigurerte allereie svarar. Viss notatet seier at den andre sida treng ei returrute, veit neste person at fjerning av masquerade-regelen bryt tilkoplinga. Dokumentasjon er billeg her; å gjenoppdage ein NAT-avhengigheit klokka tre om natta er det ikkje.