Bereik 'n afgeleë /24 deur 'n tonnel: NETMAP, DNAT of roete?
Karteer 'n hele voorvoegsel met NETMAP, voeg DNAT-reëls per gasheer by of roeteer die werklike reeks, en besluit op grond van wat die oorkant moet sien en wie verkeer mag begin.
Jy kan 'n subnet agter 'n tonnel-eindpunt op drie maniere bereik, en 'n minuut se feiteversameling skakel gewoonlik twee daarvan uit. Die feite is of die bedieners daar buite gebruikers van mekaar moet onderskei, of iemand daar ooit na jou reeks sal skakel, en wie die ver-rekenaar se roeteerder mag wysig. Beantwoord dié drie en die ontwerp kies homself. Die res aanvaar dat jy die eindpunt bestuur en sy firewall mag wysig.
Drie opsies, en wat elkeen werklik verander
Voorvoegselkartering, DNAT per gasheer en 'n geroteerde voorvoegsel beweeg almal pakkette tussen dieselfde twee reekse, maar hulle verander verskillende dinge. Kartering bedink 'n alias-reeks en herskryf adresse rekenkundig tydens die vlug. Reëls per gasheer herskryf ook, behalwe dat elke bestemming met die hand genoem word. 'n Geroteerde voorvoegsel herskryf niks: pakkette behou die werklike adresse en beide kante stem saam oor waar daardie adresse woon.
| 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 |
Begin die uitskakeling aan die oorkant, waar die beperkings die moeilikste is om te verander. As 'n bediener daar kliëntadresse in logs skryf, dit teen 'n toelaatlys kontroleer of dit aan 'n ander stelsel oorhandig, vernietig die vertaling van die bron sy enigste identifiseerder. As die oorkant ook moet inbel, val vertaling heeltemal weg, want niks daar weet die alias bestaan nie. Eers wanneer die oorkant bloot versoeke beantwoord, word die goedkoper opsies veilig.
Voorvoegselpare, en waarom die groottes moet ooreenstem
NETMAP is 'n nat-tabel-teiken wat op 'n paar voorvoegsels van dieselfde lengte werk. Dit het geen tabel per adres binne nie: dit stroop die voorvoegsel, hou die gasheer-bisse en heg hulle weer aan die nuwe voorvoegsel, en daarom karteer 'n /24 op 'n /24 en nooit op 'n /25 nie. Posisie bepaal rigting: 'n bestemmingspassing in PREROUTING herskryf waar 'n pakket heen gaan, en 'n bronpassing in POSTROUTING herskryf waar dit vandaan kom.
'n Gasheer by 192.168.2.17 verskyn vir jou kliënte as 10.50.1.17, en die laaste oktett is nie decoratief nie — dit is dieselfde getal aan beide kante. Voeg môre 'n gasheer by 192.168.2.40 en sy alias is 10.50.1.40, sonder enige reël om te wysig.
Kliënte het steeds 'n roete vir die alias-reeks nodig wat na jou boks wys, tensy die alias binne 'n subnet val wat hulle reeds bereik. Die gwewei het geen roete vir die alias nodig nie, want bestemmingsvertaling loop in PREROUTING, voor die roete-soektog. Voortstuur moet ook aan wees, anders laat die kernel die pakket na die herskrywing val. Die drie opdragte hieronder is die hele opstelling op 'n Debian-tipe gwewei met kliënte op br0, die alias op 10.50.1.0/24 en die tonnel op 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 MASQUERADEDie antwoord moet sy eie pad terug vind
Die herskryf van die bestemming bepaal net waar 'n pakket afgelewer word. Die ver-oorkant se bediener moet steeds 'n adres antwoord wat hy kan bereik, en daar is twee maniere om dit te reël. Vertaal die bron sodat antwoorde na jou boks terugkeer, of laat die bron alleen en gee die oorkant 'n roete vir die kliëntreeks.
Masquerade op die uitpad is die korter weg: een reël in POSTROUTING en die oorkant sien jou tonneladres, so dit het geen eie roete nodig nie. Die koste is dat elke gebruiker in een adres saamsmelt, en logs per gebruiker hou op om iets te beteken. Om die bron ongeskonde te laat, behou daardie inligting, maar die ver-lokasie moet dan antwoorde vir die kliëntreeks deur die tonnel terugstuur. Op 'n OpenVPN bediener is dit 'n gestuurde push "route 10.50.9.0 255.255.255.0", plus 'n route 192.168.2.0 255.255.255.0 reël.
Die duur fout is om die helfte van elkeen te doen. As jy sommige verkeer masjineer terwyl die oorkant ook 'n terugroete vir ander verkeer dra, kom antwoorde op 'n koppelvlak waar die verbinding-spoor-inskrywing nooit gesien is nie. Die kliënt rapporteer 'n tydsverloop vir 'n versoek wat die bediener as bedien gelog het. Beide rigtings van 'n vloei moet dieselfde netfilter-instansie kruis: een gwewei wat vertaal, nie twee firewalls in reeks nie.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLees die inskrywing in beide rigtings: die oorspronklike tuple hou jou alias op die bestemming, terwyl die antwoord-tuple die werklike adres dra. As die antwoord-tuple ontbreek, is die terugpad die probleem eerder as die reël. As die PREROUTING-tellers nooit beweeg het nie, het die pakket nooit daardie haak bereik nie.
Botsings en die soektog wat eerste loop
Twee verskillende reekse kan bots, en albei foute lyk soos 'n stukkende tonnel eerder as 'n slegte reël. Die alias wat jy bedink, moet ongebruik wees langs die hele pad, en die werklike ver-oorkant-reeks mag nie reeds op jou netwerk bestaan nie. 'n Duplikaat veroorsaak onreëlmatige verkeer na die verkeerde gasheer, wat moeiliker is om te diagnoseer as 'n geweierde verbinding. Vra die roetetabel voordat jy 'n reël byvoeg.
Op die gwewei, ip route get 192.168.2.17 moet die tonnel-toestel noem; 'n plaaslike brug beteken die ver-reeks word oorskadu en geen nat-reël sal dit herstel nie. As jou eie netwerk reeds 192.168.2.0/24 gebruik, hernommer die ver-lokasie eerder as om 'n kartering op die botsing te stapel.
Toets dit van 'n werklike kliënt, en hou dit dan
Toets van 'n masjien wat die alias werklik sal gebruik, nie van die gwewei nie, want plaaslik gegenereerde verkeer beweeg nooit op dieselfde manier deur PREROUTING nie. Maak 'n verbinding na een gealiaseerde gasheer oop en kyk hoe die tellers en die conntrack-inskrywing saam verskyn, sluit dit dan en bevestig dat die inskrywing verdwyn. 'n Verouderde inskrywing wys op 'n halfoop verbinding, wat gewoonlik beteken die antwoord het nooit teruggekom nie.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Twee of drie suksesvolle verbindings bewys die rekenkunde, maar hulle sê niks oor blywendheid of oor die volgende ingenieur nie. Stoor die reëls waar die selflaaiproes hulle lees, wat op Debian en Ubuntu iptables-save > /etc/iptables/rules.v4 met netfilter-persistent geaktiveer beteken. 'n Kartering wat by herbegin verdwyn, is erger as geen, want die onderbreking kom sonder 'n onlangse verandering om te blameer.
Los 'n nota langs die reëls: die alias-reeks, die werklike reeks, die rede vir die paar en watter kant mag begin. Daardie nota skei 'n ontwerp van 'n hoop reëls wat niemand durf verwyder nie. Dit besleg ook die later vraag, wanneer die ver-lokasie 'n gasheer byvoeg en 'n adres wat niemand opgestel het, reeds antwoord. As die nota sê die oorkant het 'n terugroete nodig, weet die volgende persoon dat die verwydering van die masquerade-reël konnektiwiteit breek. Dokumentasie is hier goedkoop; om 'n NAT-afhanklikheid om drie in die oggend te herontdek, is nie.