Dosiahnuť vzdialenú /24 cez tunel: NETMAP, DNAT alebo trasa?
Zmapujte celý prefix pomocou NETMAP, pridajte pravidlá DNAT pre každý host alebo smerujte skutočný rozsah, a rozhodnite podľa toho, čo musí vidieť druhá strana a kto môže začať prevádzku.
K podsieti za koncovým bodom tunela sa dá dostať tromi spôsobmi a minúta zbierania faktov zvyčajne dva vylúči. Fakty sú, či tamojšie servery musia rozlišovať používateľov, či sa odtiaľ niekto niekedy pripojí k vášmu rozsahu, a kto môže upravovať vzdialený router. Odpovedzte na tieto tri a dizajn sa vyberie sám. Zvyšok predpokladá, že spravujete koncový bod a môžete upraviť jeho firewall.
Tri možnosti a čo každá z nich naozaj mení
Mapovanie prefixu, DNAT pre každý host a smerovaný prefix presúvajú pakety medzi tými istými dvoma rozsahmi, ale menia rôzne veci. Mapovanie vymýšľa rozsah aliasov a aritmeticky prepisuje adresy za letu. Pravidlá pre hosty tiež prepisujú, len každý cieľ sa určuje ručne. Smerovaný prefix neprepisuje nič: pakety si zachovávajú skutočné adresy a oba konce sa zhodujú na tom, kde tieto 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 |
Elimináciu začnite na vzdialenej strane, kde sa obmedzenia menia najťažšie. Ak tamojší server zapisuje adresy klientov do logov, kontroluje ich voči zoznamu povolených alebo ich odovzdáva inému systému, preklad zdroja zničí jeho jediný identifikátor. Ak sa vzdialená strana musí aj pripájať dovnútra, preklad je úplne vylúčený, pretože tam nikto nevie, že alias existuje. Až keď vzdialená strana iba odpovedá na požiadavky, lacnejšie možnosti sa stanú bezpečnými.
Dvojice prefixov a prečo sa veľkosti musia zhodovať
NETMAP je cieľ tabuľky nat, ktorý pracuje na dvojici prefixov rovnakej dĺžky. Vnútri nemá tabuľku pre každú adresu: odstráni prefix, zachová bity hosta a pripojí ich k novému prefixu, preto sa /24 mapuje na /24 a nikdy na /25. Poloha určuje smer: zhoda cieľa v PREROUTING prepisuje, kam paket ide, a zhoda zdroja v POSTROUTING prepisuje, odkiaľ prišiel.
Host na 192.168.2.17 sa vašim klientom javí ako 10.50.1.17 a posledný oktet nie je dekorácia — je to rovnaké číslo na oboch stranách. Pridajte zajtra host na 192.168.2.40 a jeho alias je 10.50.1.40, bez pravidla na úpravu.
Klienti stále potrebujú trasu pre rozsah aliasov smerujúcu k vášmu boxu, pokiaľ alias nepatrí do podsiete, ktorú už dosahujú. Brána nepotrebuje trasu pre alias, pretože preklad cieľa beží v PREROUTING, pred vyhľadaním trasy. Aj preposielanie musí byť zapnuté, inak jadro paket po prepise zahodí. Tri príkazy nižšie sú celá konfigurácia na bráne v štýle Debian s klientmi na br0, aliasom na 10.50.1.0/24 a tunelom 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 MASQUERADEOdpoveď si musí sama nájsť cestu späť
Prepis cieľa rozhoduje iba o tom, kam sa paket doručí. Vzdialený server stále musí odpovedať na adresu, ku ktorej sa dostane, a to sa dá zariadiť dvoma spôsobmi. Preložte zdroj, aby sa odpovede vracali k vášmu boxu, alebo nechajte zdroj a dajte vzdialenej strane trasu pre rozsah klientov.
Masquerade na výstupe je kratšia cesta: jedno pravidlo v POSTROUTING a vzdialená strana vidí vašu adresu tunela, takže nepotrebuje vlastnú trasu. Cenou je, že každý používateľ sa zrúti do jednej adresy a logy na používateľa prestanú niečo znamenať. Ak necháte zdroj nedotknutý, informácia sa zachová, ale potom musí vzdialená lokalita posielať odpovede pre rozsah klientov späť cez tunel.OpenVPN serveri je to push-ovaná push "route 10.50.9.0 255.255.255.0", plus route 192.168.2.0 255.255.255.0 riadok.
Drahé zlyhanie je robiť polovicu z každého. Ak maskujete časť prevádzky, kým vzdialená strana nesie aj spätnú trasu pre inú prevádzku, odpovede prichádzajú na rozhranie, kde záznam sledovania spojenia nikdy nevidel. Klient hlási časový limit pre požiadavku, ktorú server zaznamenal ako obslúženú. Oba smery toku musia prejsť tou istou inštanciou netfilter: jedna brána prekladá, nie dva firewally v sérii.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nČítajte záznam v oboch smeroch: pôvodný tuple si drží váš alias v cieli, kým tuple odpovede nesie skutočnú adresu. Ak tuple odpovede chýba, problémom je spätná cesta, nie pravidlo. Ak sa počítadlá PREROUTING nikdy nepohli, paket sa k tomu hooku nikdy nedostal.
Kolízie a vyhľadanie, ktoré beží prvé
Dva rôzne rozsahy môžu kolidovať a obe zlyhania vyzerajú ako pokazený tunel, nie ako zlé pravidlo. Alias, ktorý vymyslíte, musí byť nepoužitý pozdĺž celej cesty a skutočný vzdialený rozsah nesmie už existovať vo vašej sieti. Duplikát spôsobuje občasnú prevádzku na nesprávny host, čo sa diagnostikuje ťažšie ako odmietnuté spojenie. Pred pridaním pravidla sa opýtajte smerovacej tabuľky.
Na bráne, ip route get 192.168.2.17 by malo uviesť zariadenie tunela; lokálny bridge znamená, že vzdialený rozsah je zatienený a žiadne nat pravidlo to neopraví. Ak vaša sieť už používa 192.168.2.0/24, prečíslujte vzdialenú lokalitu namiesto vrstvenia mapovania na kolíziu.
Testovanie z reálneho klienta a potom zachovanie
Testujte zo stroja, ktorý bude alias naozaj používať, nie z brány, pretože lokálne generovaná prevádzka nikdy neprechádza PREROUTING rovnako. Otvorte spojenie na jeden host s aliasom a sledujte, ako sa počítadlá a záznam conntrack objavia spolu, potom ho zatvorte a potvrďte, že záznam zmizne. Zastaraný záznam ukazuje na polootvorené spojenie, čo zvyčajne znamená, že odpoveď sa nikdy nevrátila.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Dve alebo tri úspešné spojenia dokazujú aritmetiku, ale nehovoria nič o trvácnosti ani o ďalšom inžinierovi. Ukladajte pravidlá tam, kde ich číta proces zavádzania, čo v Debiane a Ubuntu znamená iptables-save > /etc/iptables/rules.v4 so zapnutým netfilter-persistent. Mapovanie, ktoré po reštarte zmizne, je horšie ako žiadne, pretože výpadok prichádza bez nedávnej zmeny, z ktorej by sa dalo obviniť.
Nechajte pri pravidlách poznámku: rozsah aliasov, skutočný rozsah, dôvod dvojice a ktorá strana môže iniciovať. Tá poznámka oddeľuje dizajn od kopy pravidiel, ktoré sa nikto neodváži zmazať. Rieši aj neskoršiu otázku, keď vzdialená lokalita pridá host a adresa, ktorú nikto nenakonfiguroval, už odpovedá. Ak poznámka hovorí, že vzdialená strana potrebuje spätnú trasu, ďalší človek vie, že odstránenie masquerade pravidla preruší pripojenie. Dokumentácia je tu lacná; znovuobjavenie závislosti od NAT o tretej ráno nie.