Nå et eksternt /24 gjennom en tunnel: NETMAP, DNAT eller rute?
Kartlegg et helt prefiks med NETMAP, legg til DNAT-regler per vert eller rut det virkelige området, og avgjør ut fra hva den andre siden må se og hvem som kan starte trafikk.
Du kan nå et subnett bak et tunnelendepunkt på tre måter, og ett minutt med faktainnsamling diskvalifiserer vanligvis to. Faktaene er om serverne der borte må skille brukere, om noen der noen gang vil ringe mot området ditt, og hvem som kan redigere ruteren i den andre enden. Svar på de tre, og designet velger seg selv. Resten forutsetter at du driver endepunktet og kan redigere brannmuren der.
Tre alternativer, og hva hvert av dem faktisk endrer
Prefikskartlegging, DNAT per vert og et rutet prefiks flytter alle pakker mellom de samme to områdene, men de endrer forskjellige ting. Kartlegging finner opp et aliasområde og skriver om adresser aritmetisk underveis. Regler per vert skriver også om, bortsett fra at hver destinasjon navngis for hånd. Et rutet prefiks skriver om ingenting: pakkene beholder de virkelige adressene, og begge ender er enige om hvor disse adressene 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 |
Start elimineringen på den andre siden, der begrensningene er vanskeligst å endre. Hvis en server der skriver klientadresser til logger, sjekker dem mot en tillatelsesliste eller gir dem videre til et annet system, ødelegger oversettelse av kilden dens eneste identifikator. Hvis den andre siden også må ringe inn, er oversettelse helt utelukket, fordi ingen der vet at aliaset finnes. Bare når den andre siden bare svarer på forespørsler, blir de billigere alternativene trygge.
Prefikspar, og hvorfor størrelsene må stemme
NETMAP er et mål i nat-tabellen som arbeider på et par prefikser av identisk lengde. Det har ingen tabell per adresse inni: det fjerner prefikset, beholder vertsbitene og fester dem til det nye prefikset, og derfor kartlegges et /24 til et /24 og aldri til et /25. Posisjonen avgjør retningen: et destinasjonsmatch i PREROUTING skriver om hvor en pakke skal, og et kildematch i POSTROUTING skriver om hvor den kom fra.
En vert på 192.168.2.17 vises for klientene dine som 10.50.1.17, og den siste oktetten er ikke dekorasjon — det er samme tall på begge sider. Legg til en vert på 192.168.2.40 i morgen, og aliaset er 10.50.1.40, uten regler å redigere.
Klientene trenger fortsatt en rute for aliasområdet som peker mot boksen din, med mindre aliaset faller innenfor et subnett de allerede når. Gatewayen trenger ingen rute for aliaset, fordi destinasjonsoversettelsen kjører i PREROUTING, før ruteoppslaget. Videresending må også være på, ellers slipper kjernen pakken etter omskrivingen. De tre kommandoene nedenfor er 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å finne veien tilbake selv
Omskriving av destinasjonen avgjør bare hvor en pakke leveres. Serveren på den andre siden må fortsatt svare på en adresse den når, og det kan ordnes på to måter. 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 kortere veien: én regel i POSTROUTING, og den andre siden ser tunneladressen din, så den trenger ingen egen rute. Prisen er at hver bruker kollapser til én adresse, og logger per bruker slutter å bety noe. Å la kilden være intakt beholder 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. Hvis du maskerer noe trafikk mens den andre siden også har en returrute for annen trafikk, kommer svarene inn på et grensesnitt der tilkoblingssporingsoppføringen aldri ble sett. Klienten rapporterer tidsavbrudd for en forespørsel serveren loggførte som betjent. 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. Hvis svar-tuplen mangler, er problemet returveien, ikke regelen. Hvis PREROUTING-tellerne aldri har flyttet seg, nådde pakken aldri den kroken.
Kollisjoner og oppslaget som kjører 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 avbrutt trafikk til feil vert, 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 tunnel-enheten; en lokal bro betyr at det fjerne området er skyggelagt og ingen nat-regel reparerer det. Hvis nettverket ditt allerede bruker 192.168.2.0/24, omnummerer det fjerne nettstedet i stedet for å stable en kartlegging på kollisjonen.
Teste det fra en virkelig klient, og deretter beholde det
Test fra en maskin som faktisk skal bruke aliaset, ikke fra gatewayen, fordi lokalt generert trafikk aldri krysser PREROUTING på samme måte. Åpne en tilkobling til én vert med alias og se tellerne og conntrack-oppføringen dukke opp sammen, lukk den så og bekreft at oppføringen forsvinner. En gammel oppføring peker på en halvåpen tilkobling, som vanligvis 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 vellykkede tilkoblinger beviser aritmetikken, men de sier ingenting om varighet eller om neste ingeniør. Lagre reglene der oppstartsprosessen leser dem, som på Debian og Ubuntu betyr iptables-save > /etc/iptables/rules.v4 med netfilter-persistent aktivert. En kartlegging som forsvinner ved omstart er verre enn ingen, fordi avbruddet kommer uten en nylig endring å skylde på.
Legg igjen et notat ved reglene: aliasområdet, det virkelige området, grunnen til paret og hvilken side som kan initiere. Notatet skiller et design fra en haug med regler ingen tør å slette. Det avgjør også det senere spørsmålet, når det fjerne nettstedet legger til en vert og en adresse ingen konfigurerte allerede svarer. Hvis notatet sier at den andre siden trenger en returrute, vet neste person at fjerning av masquerade-regelen bryter tilkoblingen. Dokumentasjon er billig her; å gjenoppdage en NAT-avhengighet klokken tre om natten er det ikke.