Eng entfernt /24 duerch en Tunnel erreechen: NETMAP, DNAT oder Route?
E ganze Präfix mat NETMAP ofbilden, DNAT-Regelen pro Host derbäisetzen oder de richtege Beräich routeiren, an decidéieren no deem, wat déi aner Säit gesinn muss a wien den Traffic däerf ufänken.
Dir kënnt en Ënnersubnet hannert engem Tunnel-Endpunkt op dräi Manéieren erreechen, an eng Minutt Faktensammlung disqualifizéiert meeschtens zwee dovun. D'Fakten sinn, ob d'Servere dobaussen d'Benotzer mussen auserneenhalen, ob iergendeen do jee a Richtung Äre Beräich wäert goen, a wien de Router um aneren Enn däerf änneren. Äntwert op dës dräi, an den Design wielt sech selwer. De Rescht geet dovun aus, datt Dir den Endpunkt bedreift an d'Firewall drun däerft änneren.
Dräi Optiounen, an wat jidderee wierklech ännert
Präfix-Mapping, DNAT pro Host an e geroutete Präfix beweegen all Pakete tëscht deenen zwee selwechte Beräicher, awer si änneren ënnerschiddlech Saachen. Mapping erfindet en Alias-Beräich a schreift Adressen am Fluch arithmetesch ëm. Per-Host-Regele schreiwen och ëm, just datt all Destinatioun vun Hand genannt gëtt. E geroutete Präfix schreift näischt ëm: d'Pakete behalen déi richteg Adressen an déi zwou Säiten eenegen sech drop, wou dës Adressen ze fannen sinn.
| 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 |
Fänkt d'Eliminatioun op der anerer Säit un, wou d'Aschränkungen am schwéiersten ze änneren sinn. Wann e Server do d'Clientadressen a Loggen schreift, se géint eng Erlaabnislëscht préift oder se un en anert System weider gëtt, zerstéiert d'Iwwersetze vun der Quell säin eenzegen Identifiant. Wann déi aner Säit och muss erakommen, fällt d'Iwwersetzung komplett ewech, well do kee weess, datt den Alias existéiert. Nëmmen wann déi aner Säit just Ufroe beäntwert, gi méi bëlleg Optiounen sécher.
Präfix-Pueren, a firwat d'Gréissten mussen iwwereneestëmmen
NETMAP ass en Zil vun der nat-Tabell, dat op engem Puer vu Präfixer vun identescher Längt schafft. Et huet keng Tabell pro Adress banne: et zitt de Präfix of, behält d'Host-Bitten a befestegt se un de neie Präfix, dofir gëtt eng /24 op eng /24 ofgebilt an ni op eng /25. D'Positioun entscheet d'Richtung: eng Destinatiouns-Harmonie am PREROUTING schreift ëm, wou e Paket higeet, an eng Quell-Harmonie am POSTROUTING schreift ëm, wou et hierkënnt.
En Host op 192.168.2.17 erschéngt Ären Cliente wéi 10.50.1.17, an dat lescht Oktett ass keng Dekoratioun — et ass déiselwecht Zuel op béide Säiten. Füügt muer en Host op 192.168.2.40 bäi, an säin Alias ass 10.50.1.40, ouni Regel déi een ännere muss.
D'Cliente brauchen nach ëmmer eng Route fir den Alias-Beräich, déi op Är Këscht weist, ausser den Alias fält an en Ënnersubnet, deen se schonn erreechen. De Gateway brauch keng Route fir den Alias, well d'Destinatiouns-Iwwersetzung am PREROUTING leeft, virun der Route-Sich. Forwarding muss och un sinn, soss verwërft de Kernel d'Paket no der Ëmschreifung. Déi dräi Kommandoen hei drënner sinn déi ganz Konfiguratioun op engem Gateway am Debian-Stil mat Cliente op br0, dem Alias op 10.50.1.0/24 an dem Tunnel 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 MASQUERADED'Äntwert muss hire Wee zréck selwer fannen
D'Destinatioun ëmschreiwen entscheet just, wou e Paket ausgeliwwert gëtt. De Server op der anerer Säit muss nach ëmmer op eng Adress äntwerten, déi en erreechen kann, an et gëtt zwee Weeër, dat anzeurichten. Iwwersetzt d'Quell, sou datt d'Äntwerten op Är Këscht zréckkommen, oder loosst d'Quell a gitt der anerer Säit eng Route fir de Client-Beräich.
Masquerading um Wee no baussen ass de kierzere Wee: eng Regel am POSTROUTING an déi aner Säit gesäit Är Tunneladress, dofir brauch se keng eegen Route. De Präis ass, datt all Benotzer an eng eenzeg Adress zesummefält, an d'Logge pro Benotzer bedäiten näischt méi. D'Quell intakt loossen erhält dës Informatioun, awer de Site op der anerer Säit muss dann d'Äntwerten fir de Client-Beräich duerch den Tunnel zréckschécken.OpenVPN Server ass dat eng push "route 10.50.9.0 255.255.255.0", plus eng route 192.168.2.0 255.255.255.0 Linn.
De deieren Echec ass, vun all deem d'Halschent ze maachen. Wann Dir en Deel vum Traffic masquerade-ts, während déi aner Säit och eng Réckroute fir aneren Traffic dréit, kommen d'Äntwerten op engem Interface un, wou den Connection-Tracking-Agank ni gesi gouf. De Client mellt en Timeout fir eng Ufro, déi de Server als beäntwert protokolléiert hat. Béid Richtunge vun engem Floss mussen duerch déiselwecht netfilter-Instanz goen: ee Gateway iwwersetzt, net zwee Firewallen hannereen.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLiest den Agank a béid Richtungen: den originellen Tuple behält Ären Alias op der Destinatioun, während den Äntwert-Tuple déi richteg Adress dréit. Fehlt den Äntwert-Tuple, ass de Réckwee de Problem an net d'Regel. Hunn sech d'PREROUTING-Zieler ni beweegt, huet d'Paket dëse Hook ni erreecht.
Kollisiounen an d'Sich, déi als éischt leeft
Zwee ënnerschiddlech Beräicher kënnen kollidéieren, an béid Feeler gesi wéi en kaputten Tunnel aus, net wéi eng schlecht Regel. Den Alias, deen Dir erfindet, muss iwwer de ganze Wee onbenotzt sinn, an de richtege Beräich op der anerer Säit däerf et an Ärem Netzwierk nach net ginn. Eng Duplikat produzéiert ënnerbrache falschen Host-Traffic, deen schwéier ze diagnostizéieren ass wéi eng ofgeleent Verbindung. Frot d'Routing-Tabell, ier Dir eng Regel derbäisetzt.
Op dem Gateway, ip route get 192.168.2.17 sollt den Tunnel-Apparat nennen; eng lokal Bréck heescht, datt de Beräich op der anerer Säit iwwerschatt ass an keng nat-Regel en reparéiert. Wann Äert Netzwierk schonn 192.168.2.0/24 benotzt, numeréiert de Site op der anerer Säit nei, amplaz eng Mapping op d'Kollisioun ze stapelen.
Vun engem richtege Client testen, duerno behalen
Test vun enger Maschinn, déi den Alias wierklech benotzt, net vum Gateway, well lokal generéierten Traffic den PREROUTING ni op déiselwecht Manéier duerchleeft. Maacht eng Verbindung op een Host mat Alias op a kuckt, wéi d'Zieler an den conntrack-Agank zesummen erschéngen, da maacht se zou a bestätegt, datt den Agank fortgeet. En ale Agank weist op eng hallefoppen Verbindung, wat meeschtens heescht, datt d'Äntwert ni zréckkomm ass.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Zwee oder dräi erfollegräich Verbindunge beweisen d'Arithmetik, awer si soen näischt iwwer d'Persistenz oder den nächsten Ingenieur. Späichert d'Regele do, wou de Bootprozess se liest, wat op Debian an Ubuntu iptables-save > /etc/iptables/rules.v4 mat aktivéiertem netfilter-persistent heescht. Eng Mapping, déi beim Reboot verschwënnt, ass méi schlëmm wéi keng, well den Ausfall ouni eng rezent Ännerung kënnt, déi een beschëllegen kann.
Loosst eng Notiz nieft de Regele: den Alias-Beräich, de richtege Beräich, de Grond fir d'Puer a wéi eng Säit däerf ufänken. Dës Notiz trennt en Design vun engem Koup Regele, déi kee sech traut ze läschen. Si léist och déi spéider Fro, wann de Site op der anerer Säit en Host bäisetzt an eng Adress, déi keen konfiguréiert huet, schonn äntwert. Wann d'Notiz seet, datt déi aner Säit eng Réckroute brauch, weess déi nächst Persoun, datt d'Ewechhuele vun der Masquerade-Regel d'Konnektivitéit brécht. Dokumentatioun ass hei bëlleg; eng NAT-Ofhängegkeet ëm dräi Auer moies erëmzefannen ass et net.