Dosáhnout vzdálené /24 tunelem: NETMAP, DNAT, nebo routa?
Zmapujte celý prefix pomocí NETMAP, přidejte pravidla DNAT pro jednotlivé hosty, nebo routujte skutečný rozsah, a rozhodněte podle toho, co musí vzdálená strana vidět a kdo smí začínat provoz.
K podsíti za koncovým bodem tunelu se dostanete třemi způsoby a minuta zjišťování faktů obvykle dva vyloučí. Fakta jsou: zda tamější servery musí rozlišovat uživatele, zda odtamtud někdy někdo zavolá směrem k vašemu rozsahu a kdo smí upravovat router na vzdálené straně. Odpovězte na tyto tři a návrh se vybere sám. Zbytek předpokládá, že koncový bod spravujete vy a smíte upravovat jeho firewall.
Tři možnosti a co každá z nich skutečně mění
Mapování prefixu, DNAT pro jednotlivé hosty i routovaný prefix přenášejí pakety mezi stejnými dvěma rozsahy, ale mění různé věci. Mapování vymýšlí alias rozsah a přepisuje adresy aritmeticky za letu. Pravidla pro jednotlivé hosty také přepisují, jen se každé cílové adrese přiřazuje ručně. Routovaný prefix nepřepisuje nic: pakety si ponechávají skutečné adresy a obě strany se shodnou, kde tyto adresy žijí.
| 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 |
Eliminaci začněte na vzdálené straně, kde se omezení mění nejtěžší. Pokud tamější server zapisuje adresy klientů do logů, kontroluje je proti seznamu povolených nebo je předává jinému systému, překlad zdroje zničí jeho jediný identifikátor. Pokud se vzdálená strana musí také ozvat, překlad úplně padá, protože tam nikdo neví, že alias existuje. Teprve když vzdálená strana pouze odpovídá na požadavky, jsou levnější možnosti bezpečné.
Dvojice prefixů a proč musí velikosti odpovídat
NETMAP je cíl tabulky nat, který pracuje s dvojicí prefixů stejné délky. Uvnitř nemá tabulku pro každou adresu: odebere prefix, ponechá bity hostitele a připojí je k novému prefixu, proto se /24 mapuje na /24 a nikdy na /25. Pozice určuje směr: shoda cíle v PREROUTING přepisuje, kam paket jde, a shoda zdroje v POSTROUTING přepisuje, odkud přišel.
Hostitel na 192.168.2.17 se vašim klientům jeví jako 10.50.1.17 a poslední oktet není dekorace — je to stejné číslo na obou stranách. Přidejte zítra hostitele na 192.168.2.40 a jeho alias je 10.50.1.40, bez pravidla k úpravě.
Klienti stále potřebují routu pro alias rozsah ukazující na váš stroj, pokud alias neleží v podsíti, kterou už dosáhnou. Brána nepotřebuje pro alias žádnou routu, protože překlad cíle běží v PREROUTING před vyhledáním routy. Přeposílání musí být také zapnuté, jinak jádro paket po přepisu zahodí. Tři příkazy níže jsou celé nastavení na bráně ve stylu Debianu s klienty na br0, aliasem na 10.50.1.0/24 a tunelem na 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 MASQUERADEOdpověď si musí najít vlastní cestu zpět
Přepsání cíle jen rozhoduje, kam bude paket doručen. Server na vzdálené straně stále musí odpovědět na adresu, kterou dosáhne, a zařídit to lze dvěma způsoby. Přeložte zdroj, aby se odpovědi vracely na váš stroj, nebo zdroj nechte být a dejte vzdálené straně routu pro rozsah klientů.
Maskování na cestě ven je kratší cesta: jedno pravidlo v POSTROUTING a vzdálená strana vidí adresu vašeho tunelu, takže nepotřebuje vlastní routu. Cenou je, že se všichni uživatelé slijí do jedné adresy a logy po uživatelích přestanou něco znamenat. Ponechání zdroje nedotčeného tuto informaci zachová, ale vzdálené místo pak musí posílat odpovědi pro rozsah klientů zpět tunelem. Na OpenVPN serveru to je odeslané push "route 10.50.9.0 255.255.255.0", plus řádek route 192.168.2.0 255.255.255.0.
Drahá chyba je udělat půlku od každého. Pokud maskujete část provozu, zatímco vzdálená strana také nese zpětnou routu pro jiný provoz, odpovědi dorazí na rozhraní, kde záznam sledování spojení nikdy nebyl viděn. Klient hlásí vypršení času u požadavku, který server zalogoval jako obsloužený. Oba směry toku musí projít stejnou instancí netfilter: jedna brána překládá, ne dva firewally v řadě.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nPřečtěte záznam v obou směrech: původní tuple drží váš alias v cíli, zatímco tuple odpovědi nese skutečnou adresu. Pokud tuple odpovědi chybí, problémem je zpětná cesta, nikoli pravidlo. Pokud se čítače PREROUTING nikdy nepohnuly, paket se k tomuto hooku nikdy nedostal.
Kolize a vyhledání, které probíhá první
Dva různé rozsahy mohou kolidovat a obě selhání vypadají jako rozbitý tunel, ne jako špatné pravidlo. Alias, který vymyslíte, musí být nepoužitý po celé cestě a skutečný rozsah vzdálené strany nesmí už ve vaší síti existovat. Duplikát vytváří občasný provoz ke špatnému hostiteli, což se diagnostikuje hůř než odmítnuté spojení. Zeptejte se routovací tabulky, než přidáte pravidlo.
Na bráně by ip route get 192.168.2.17 mělo pojmenovat zařízení tunelu; místní bridge znamená, že vzdálený rozsah je zastíněn a žádné pravidlo nat to nespraví. Pokud vaše síť už používá 192.168.2.0/24, přečíslujte vzdálené místo, místo abyste na kolizi vrstvili mapování.
Otestovat ze skutečného klienta a pak si to ponechat
Testujte ze stroje, který bude alias skutečně používat, ne z brány, protože lokálně generovaný provoz nikdy neprochází PREROUTING stejně. Otevřete spojení k jednomu hostiteli s aliasem a sledujte, jak se čítače a záznam conntrack objeví společně, pak ho zavřete a potvrďte, že záznam zmizí. Zastaralý záznam ukazuje na polootevřené spojení, což obvykle znamená, že odpověď nikdy nepřišla.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Dvě nebo tři úspěšná spojení dokazují aritmetiku, ale nic neříkají o trvalosti ani o dalším inženýrovi. Uložte pravidla tam, kde je čte proces zavádění, což v Debianu a Ubuntu znamená iptables-save > /etc/iptables/rules.v4 se zapnutým netfilter-persistent. Mapování, které po restartu zmizí, je horší než žádné, protože výpadek přijde bez nedávné změny, kterou by bylo možné obvinit.
Nechte u pravidel poznámku: alias rozsah, skutečný rozsah, důvod dvojice a která strana smí iniciovat. Ta poznámka odděluje návrh od hromady pravidel, která si nikdo netroufne smazat. Řeší i pozdější otázku, když vzdálené místo přidá hostitele a adresa, kterou nikdo nenastavil, už odpovídá. Pokud poznámka říká, že vzdálená strana potřebuje zpětnou routu, další člověk ví, že odebrání pravidla maskování přeruší konektivitu. Dokumentace je tu levná; znovuobjevení závislosti na NAT ve tři ráno ne.