Nå en ekstern /24 over en tunnel: NETMAP, DNAT eller rute?
Kartlegg et helt prefiks med NETMAP, legg inn DNAT-regler per vert eller rut det reelle området, og avgjør etter hva den andre siden må se og hvem som kan starte trafikk.
Et subnett bak et tunnelendepunkt kan du nå på tre måter, og ett minutt med fakta pleier å utelukke to. Faktaene er hvorvidt serverne der borte må skille brukere, om noen der noen gang vil koble seg mot området ditt, og hvem som har lov til å endre ruteren i den andre enden. Svar på disse tre, så velger designet seg selv. Resten forutsetter at du styrer endepunktet og kan endre brannmuren der.
Tre valg, og hva hvert av dem egentlig endrer
Prefikskartlegging, DNAT per vert og et rutet prefiks flytter alle pakker mellom de samme to områdene, men de endrer ulike ting. Kartlegging oppfinner et aliasområde og skriver om adresser aritmetisk mens pakken er underveis. Regler per vert skriver også om, men hver destinasjon navngis for hånd. Et rutet prefiks skriver om ingenting: pakkene beholder de virkelige adressene, og begge sider er enige om hvor adressene hører hjemme.
| 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 |
Begynn elimineringen på den andre siden, der begrensningene er vanskeligst å endre. Skriver en server der klientadresser i logger, sjekker dem mot en tillatelsesliste eller sender dem videre til et annet system, ødelegger oversettelse av kilden dens eneste identifikator. Må den andre siden også koble inn, er oversettelse helt utelukket, fordi ingen der vet at aliaset eksisterer. Bare når den andre siden kun besvarer forespørsler, blir de billigere valgene trygge.
Prefikspar, og hvorfor størrelsene må matche
NETMAP er et mål i nat-tabellen som jobber på et par prefikser med lik lengde. Det har ingen tabell per adresse inni seg: det fjerner prefikset, beholder vertsbitene og fester dem til det nye prefikset, og derfor kartlegges en /24 til en /24 og aldri til en /25. Plasseringen bestemmer retningen: et treff på destinasjon i PREROUTING skriver om hvor pakken skal, og et treff på kilde i POSTROUTING skriver om hvor den kom fra.
En vert på 192.168.2.17 fremstår for klientene dine som 10.50.1.17, og den siste oktetten er ikke pynt — det er samme tall på begge sider. Legger du til en vert på 192.168.2.40 i morgen, er aliaset 10.50.1.40, uten regler som må endres.
Klientene trenger fortsatt en rute for aliasområdet som peker mot boksen din, med mindre aliaset ligger innenfor et subnett de allerede når. Gatewayen trenger ingen rute for aliaset, siden destinasjonsoversettelsen kjører i PREROUTING, før ruteoppslaget. Videresending må også være slått på, ellers forkaster kjernen pakken etter omskrivingen. De tre kommandoene nedenfor utgjør hele oppsettet på en Debian-lignende 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 må selv finne veien tilbake
Omskriving av destinasjonen bestemmer bare hvor pakken leveres. Serveren på den andre siden må fortsatt svare på en adresse den kan nå, og det finnes to måter å ordne det på. Oversett kilden slik at svarene kommer tilbake til boksen din, eller la kilden være og gi den andre siden en rute for klientområdet.
Masquerading på vei ut er den korteste veien: én regel i POSTROUTING, og den andre siden ser tunneladressen din, så den trenger ingen egen rute. Kostnaden er at hver bruker presses sammen til én adresse, og logger per bruker mister mening. Lar du kilden være urørt, beholdes informasjonen, men da må det fjerne nettstedet sende svar for klientområdet tilbake gjennom tunnelen.OpenVPN server er det en pushet push "route 10.50.9.0 255.255.255.0", pluss en route 192.168.2.0 255.255.255.0 linje.
Den dyre feilen er å gjøre halvparten av hver. Maskerer du noe trafikk samtidig som den andre siden også har en returrute for annen trafikk, kommer svarene inn på et grensesnitt der tilkoblingssporingsoppføringen aldri ble observert. Klienten rapporterer tidsavbrudd for en forespørsel serveren førte som besvart. Begge retninger av en flyt må krysse samme netfilter-instans: én gateway som oversetter, ikke to brannmurer i serie.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLes oppføringen i begge retninger: den opprinnelige tuple beholder aliaset ditt på destinasjonen, mens svar-tuplen bærer den virkelige adressen. Mangler svar-tuplen, er problemet returveien, ikke regelen. Har PREROUTING-tellerne aldri rørt seg, nådde pakken aldri den kroken.
Kollisjoner og oppslaget som kjøres først
To forskjellige områder kan kollidere, og begge feilene ser ut som en ødelagt tunnel snarere enn en dårlig regel. Aliaset du finner opp må være ubrukt langs hele veien, og det virkelige området på den andre siden må ikke allerede finnes på nettverket ditt. En duplikat gir uregelmessig trafikk til feil vert, noe som er vanskeligere å diagnostisere enn en avvist tilkobling. Spør rutetabellen før du legger til en regel.
På gatewayen, ip route get 192.168.2.17 skal navngi tunnelenheten; en lokal bro betyr at det fjerne området er skyggelagt, og ingen nat-regel reparerer det. Bruker nettverket ditt allerede 192.168.2.0/24, må det fjerne nettstedet omnummereres i stedet for å stable en kartlegging oppå kollisjonen.
Teste fra en virkelig klient, og så beholde det
Test fra en maskin som faktisk skal bruke aliaset, ikke fra gatewayen, fordi lokalt generert trafikk aldri krysser PREROUTING på samme vis. Åpne en tilkobling til én vert med alias, se tellerne og conntrack-oppføringen dukke opp sammen, lukk den og bekreft at oppføringen forsvinner. En foreldet oppføring peker på en halvåpen tilkobling, som oftest betyr at svaret aldri returnerte.
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 tilkoblinger beviser aritmetikken, men sier ingenting om varighet eller om den neste ingeniøren. Lagre reglene der oppstartsprosessen leser dem, som på Debian og Ubuntu betyr iptables-save > /etc/iptables/rules.v4 med netfilter-persistent slått på. En kartlegging som forsvinner ved omstart er verre enn ingen, fordi utfallet kommer uten en nylig endring å gi skylden.
Etterlat en lapp ved reglene: aliasområdet, det virkelige området, grunnen til paret og hvilken side som kan initiere. Den lappen skiller et design fra en haug regler ingen tør slette. Den avgjør også spørsmålet som kommer senere, når det fjerne nettstedet legger til en vert og en adresse ingen konfigurerte allerede svarer. Sier lappen at den andre siden trenger en returrute, vet neste person at fjerning av masquerade-regelen bryter forbindelsen. Dokumentasjon er billig her; å gjenoppdage en NAT-avhengighet klokken tre om natten er det ikke.