Egy távoli /24 elérése alagúton: NETMAP, DNAT vagy útvonal?
Képezze le a teljes előtagot NETMAP-pal, adjon hozzá DNAT-szabályokat hosztonként, vagy irányítsa a valódi tartományt, és döntsön aszerint, mit kell látnia a távoli oldalnak, és ki indíthat forgalmat.
Egy alagút végpontja mögötti alhálózatot háromféleképpen érhet el, és egy perc ténygyűjtés általában kettőt kizár. A tények: meg kell-e különböztetnie az ottani kiszolgálóknak a felhasználókat, fog-e valaki onnan valaha a tartományába hívni, és ki szerkesztheti a távoli vég routerét. Válaszoljon erre a háromra, és a tervezés magától kiválasztja magát. A többi feltételezi, hogy Ön üzemelteti a végpontot, és szerkesztheti a tűzfalát.
Három lehetőség, és mit változtat meg valójában mindegyik
Az előtagleképezés, a hosztonkénti DNAT és az irányított előtag mindegyike ugyanazon két tartomány között mozgat csomagokat, de más-más dolgot változtatnak meg. A leképezés kitalál egy alias-tartományt, és a címeket menet közben aritmetikailag átírja. A hosztonkénti szabályok is átírnak, csak minden célpontot kézzel neveznek meg. Az irányított előtag semmit nem ír át: a csomagok megtartják a valódi címeket, és mindkét vég egyetért abban, hol élnek ezek a címek.
| 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 |
A kizárást a távoli oldalon kezdje, ahol a korlátokat a legnehezebb megváltoztatni. Ha egy ottani kiszolgáló ügyfélcímeket ír a naplókba, engedélyezési listával ellenőrzi őket, vagy átadja őket egy másik rendszernek, a forrás lefordítása megsemmisíti az egyetlen azonosítójukat. Ha a távoli oldalnak is hívnia kell, a fordítás teljesen kiesik, mert ott senki nem tudja, hogy létezik az alias. Csak akkor biztonságosak az olcsóbb lehetőségek, ha a távoli oldal csak válaszol a kérésekre.
Előtagpárok, és miért kell megegyezniük a méreteknek
A NETMAP a nat tábla egyik célja, amely azonos hosszúságú előtagpáron dolgozik. Belül nincs címenkénti tábla: leveszi az előtagot, megtartja a hosztbiteket, és hozzácsatolja őket az új előtaghoz, ezért a /24 /24-re képződik le, és soha nem /25-re. A pozíció dönti el az irányt: a cél egyezése a PREROUTING-ban átírja, hová tart a csomag, a forrás egyezése a POSTROUTING-ban pedig azt, honnan jött.
A 192.168.2.17 címen lévő hoszt az ügyfelei számára 10.50.1.17-ként jelenik meg, és az utolsó oktett nem díszítés — ugyanaz a szám mindkét oldalon. Adjon hozzá holnap egy hosztot a 192.168.2.40 címen, és az aliase 10.50.1.40 lesz, egyetlen szerkesztendő szabály nélkül.
Az ügyfeleknek továbbra is kell egy útvonal az alias-tartományhoz, amely a gépére mutat, kivéve, ha az alias olyan alhálózatba esik, amelyet már elérnek. Az átjárónak nem kell útvonal az aliashez, mert a célfordítás a PREROUTING-ban fut, az útvonalkeresés előtt. A továbbításnak is be kell lennie kapcsolva, különben a kernel az átírás után eldobja a csomagot. Az alábbi három parancs a teljes beállítás egy Debian stílusú átjárón, ügyfelekkel a br0-n, az aliasszal a 10.50.1.0/24-en és az alagúttal a tun0-n.
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 MASQUERADEA válasznak magának kell megtalálnia a visszautat
A cél átírása csak azt dönti el, hová kézbesítik a csomagot. A távoli oldal kiszolgálójának továbbra is válaszolnia kell egy általa elérhető címre, és erre két mód van. Fordítsa le a forrást, hogy a válaszok visszatérjenek a gépére, vagy hagyja érintetlenül a forrást, és adjon a távoli oldalnak útvonalat az ügyféltartományhoz.
A kimenő maszkolás a rövidebb út: egy szabály a POSTROUTING-ban, és a távoli oldal az alagút címét látja, így nincs szüksége saját útvonalra. Az ár, hogy minden felhasználó egyetlen címbe olvad össze, és a felhasználónkénti naplók értelmüket vesztik. A forrás érintetlenül hagyása megőrzi ezt az információt, de akkor a távoli helynek az ügyféltartomány válaszait az alagúton keresztül kell visszaküldenie. Egy OpenVPN kiszolgálón ez egy küldött push "route 10.50.9.0 255.255.255.0", plusz egy sor route 192.168.2.0 255.255.255.0.
A drága hiba mindkettőből a felét megtenni. Ha a forgalom egy részét maszkolja, miközben a távoli oldal is visszautat hordoz egy másik forgalomhoz, a válaszok olyan interfészen érkeznek, ahol a kapcsolatkövetési bejegyzést soha nem látták. Az ügyfél időtúllépést jelent egy kérésre, amelyet a kiszolgáló kiszolgáltként naplózott. Egy folyamat mindkét irányának ugyanazon a netfilter-példányon kell átmennie: egy átjáró fordít, nem két tűzfal sorban.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nOlvassa a bejegyzést mindkét irányban: az eredeti tuple a célon tartja az aliasát, míg a válasz-tuple a valódi címet hordozza. Ha hiányzik a válasz-tuple, a visszaút a probléma, nem a szabály. Ha a PREROUTING számlálói soha nem mozdultak, a csomag soha nem érte el azt a horgot.
Ütközések és az elsőként futó keresés
Két különböző tartomány ütközhet, és mindkét hiba törött alagútnak látszik, nem rossz szabálynak. Az általa kitalált aliasnak az egész úton használatlannak kell lennie, és a távoli oldal valódi tartománya nem létezhet már a hálózatán. A duplikátum időszakos forgalmat okoz a rossz hoszthoz, amit nehezebb diagnosztizálni, mint egy elutasított kapcsolatot. Kérdezze meg az útvonaltáblát, mielőtt szabályt ad hozzá.
Az átjárón a ip route get 192.168.2.17 nevezze meg az alagút eszközét; egy helyi híd azt jelenti, hogy a távoli tartomány árnyékban van, és egyetlen nat szabály sem javítja meg. Ha a saját hálózata már használja a 192.168.2.0/24-et, számozza újra a távoli helyet, ahelyett hogy leképezést halmozna az ütközésre.
Valódi ügyfélről tesztelni, majd megtartani
Olyan gépről teszteljen, amely valóban használni fogja az aliast, ne az átjáróról, mert a helyben generált forgalom soha nem ugyanúgy halad át a PREROUTING-on. Nyisson kapcsolatot egy aliasos hoszthoz, és figyelje, ahogy a számlálók és a conntrack-bejegyzés együtt megjelennek, majd zárja be, és erősítse meg, hogy a bejegyzés eltűnik. Az elavult bejegyzés félig nyitott kapcsolatra utal, ami általában azt jelenti, hogy a válasz soha nem jött vissza.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Két vagy három sikeres kapcsolat bizonyítja az aritmetikát, de semmit nem mond a tartósságról vagy a következő mérnökről. Mentse a szabályokat oda, ahonnan a rendszerindítás olvassa őket, ami Debianon és Ubuntun iptables-save > /etc/iptables/rules.v4 és engedélyezett netfilter-persistent mellett. Az újraindításkor eltűnő leképezés rosszabb a semminél, mert a kimaradás friss változtatás nélkül érkezik, amit hibáztatni lehetne.
Hagyjon jegyzetet a szabályok mellett: az alias-tartomány, a valódi tartomány, a pár oka és hogy melyik oldal indíthat. Ez a jegyzet elválasztja a tervezést egy olyan szabályhalomtól, amelyet senki nem mer törölni. A későbbi kérdést is eldönti, amikor a távoli hely hosztot ad hozzá, és egy cím, amelyet senki nem állított be, már válaszol. Ha a jegyzet azt mondja, hogy a távoli oldalnak visszaútra van szüksége, a következő ember tudja, hogy a maszkolási szabály eltávolítása megszakítja a kapcsolatot. A dokumentáció itt olcsó; a NAT-függőség újrafelfedezése hajnali háromkor nem az.