Nå ett avlägset /24 genom en tunnel: NETMAP, DNAT eller rutt?
Mappa ett helt prefix med NETMAP, lägg till DNAT-regler per värd eller routa det verkliga intervallet, och avgör utifrån vad den andra sidan måste se och vem som får starta trafik.
Du kan nå ett subnät bakom en tunneländpunkt på tre sätt, och en minut av faktainsamling brukar diskvalificera två. Fakta är om servrarna där borta måste skilja användare, om någon där någonsin kommer att ringa mot ditt intervall, och vem som får redigera routern i andra änden. Svara på de tre och designen väljer sig själv. Resten förutsätter att du driver ändpunkten och får redigera dess brandvägg.
Tre alternativ, och vad var och en faktiskt ändrar
Prefixmappning, DNAT per värd och ett routat prefix flyttar alla paket mellan samma två intervall, men de ändrar olika saker. Mappning hittar på ett aliasintervall och skriver om adresser aritmetiskt under vägen. Regler per värd skriver också om, bara att varje destination namnges för hand. Ett routat prefix skriver inte om något: paketen behåller de riktiga adresserna och båda ändar är överens om var dessa 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 |
Börja elimineringen på den andra sidan, där begränsningarna är svårast att ändra. Om en server där skriver klientadresser till loggar, kontrollerar dem mot en tillåtelselista eller lämnar dem till ett annat system, förstör översättning av källan dess enda identifierare. Om den andra sidan också måste ringa in är översättning helt utesluten, eftersom ingen där vet att aliaset finns. Först när den andra sidan bara svarar på förfrågningar blir de billigare alternativen säkra.
Prefixpar, och varför storlekarna måste stämma
NETMAP är ett mål i nat-tabellen som arbetar på ett par prefix av identisk längd. Det har ingen tabell per adress inuti: det tar bort prefixet, behåller värdbitarna och fäster dem vid det nya prefixet, därför mappas ett /24 till ett /24 och aldrig till ett /25. Positionen avgör riktningen: en destinationsmatchning i PREROUTING skriver om vart ett paket tar vägen, och en källmatchning i POSTROUTING skriver om varifrån det kom.
En värd på 192.168.2.17 syns för dina klienter som 10.50.1.17, och den sista oktetten är inte dekoration — det är samma tal på båda sidor. Lägg till en värd på 192.168.2.40 i morgon och dess alias är 10.50.1.40, utan regel att redigera.
Klienterna behöver fortfarande en rutt för aliasintervallet som pekar mot din box, om inte aliaset ligger inom ett subnät de redan når. Gatewayen behöver ingen rutt för aliaset, eftersom destinationsöversättningen körs i PREROUTING, före ruttuppslagningen. Vidarebefordran måste också vara på, annars släpper kärnan paketet efter omskrivningen. De tre kommandona nedan är hela uppsättningen på en Debian-liknande gateway med klienter på br0, aliaset på 10.50.1.0/24 och tunneln 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åste självt hitta vägen tillbaka
Att skriva om destinationen avgör bara var ett paket levereras. Servern på andra sidan måste fortfarande svara på en adress den når, och det kan ordnas på två sätt. Översätt källan så att svaren kommer tillbaka till din box, eller lämna källan och ge den andra sidan en rutt för klientintervallet.
Masquerading på väg ut är den kortare vägen: en regel i POSTROUTING och den andra sidan ser din tunneladress, så den behöver ingen egen rutt. Priset är att varje användare kollapsar till en enda adress, och loggar per användare slutar betyda något. Lämnas källan intakt bevaras informationen, men då måste den avlägsna sajten skicka svaren för klientintervallet tillbaka genom tunneln.OpenVPN server är det en pushad push "route 10.50.9.0 255.255.255.0", plus en route 192.168.2.0 255.255.255.0 rad.
Det dyra felet är att göra halva av varje. Om du maskerar en del av trafiken medan den andra sidan också bär en returrutt för annan trafik, kommer svaren in på ett gränssnitt där anslutningsspårningsposten aldrig sågs. Klienten rapporterar timeout för en förfrågan som servern loggade som betjänad. Båda riktningarna av ett flöde måste passera samma netfilter-instans: en gateway som översätter, inte två brandväggar i serie.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLäs posten i båda riktningarna: den ursprungliga tuple behåller ditt alias på destinationen, medan svarstuple bär den riktiga adressen. Om svarstuple saknas är problemet returvägen, inte regeln. Om PREROUTING-räknarna aldrig har rört sig nådde paketet aldrig den kroken.
Kollisioner och uppslagningen som körs först
Två olika intervall kan kollidera, och båda felen ser ut som en trasig tunnel snarare än en dålig regel. Aliaset du hittar på måste vara oanvänt längs hela vägen, och det riktiga avlägsna intervallet får inte redan finnas på ditt nätverk. En dubblett ger sporadisk trafik till fel värd, vilket är svårare att diagnostisera än en avvisad anslutning. Fråga rutttabellen innan du lägger till en regel.
På gatewayen, ip route get 192.168.2.17 bör namnge tunneenheten; en lokal brygga betyder att det avlägsna intervallet är överskuggat och ingen nat-regel reparerar det. Om ditt nätverk redan använder 192.168.2.0/24, numrera om den avlägsna sajten i stället för att stapla en mappning på kollisionen.
Testa det från en riktig klient och behåll det sedan
Testa från en maskin som faktiskt ska använda aliaset, inte från gatewayen, eftersom lokalt genererad trafik aldrig passerar PREROUTING på samma sätt. Öppna en anslutning till en värd med alias och se räknarna och conntrack-posten dyka upp tillsammans, stäng den sedan och bekräfta att posten försvinner. En gammal post pekar på en halvöppen anslutning, vilket oftast betyder att svaret aldrig kom tillbaka.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Två eller tre lyckade anslutningar bevisar aritmetiken, men de säger ingenting om varaktighet eller om nästa ingenjör. Spara reglerna där startprocessen läser dem, vilket på Debian och Ubuntu betyder iptables-save > /etc/iptables/rules.v4 med netfilter-persistent aktiverat. En mappning som försvinner vid omstart är värre än ingen, eftersom avbrottet kommer utan en nylig ändring att skylla på.
Lämna en anteckning bredvid reglerna: aliasintervallet, det riktiga intervallet, skälet till paret och vilken sida som får initiera. Anteckningen skiljer en design från en hög regler som ingen vågar radera. Den avgör också den senare frågan, när den avlägsna sajten lägger till en värd och en adress som ingen konfigurerade redan svarar. Om anteckningen säger att den andra sidan behöver en returrutt vet nästa person att borttagning av masquerade-regeln bryter anslutningen. Dokumentation är billig här; att återupptäcka ett NAT-beroende klockan tre på natten är det inte.