Dva klienti VPN, dvě veřejné adresy: sluďte SNAT
SNAT podle zdroje může zvolit veřejnou adresu, ale jen dokud brána ještě rozezná klienty. Před napsáním pravidla zkontrolujte přežívající zdroj.
Dva klienti VPN mohou odcházet přes dvě různé veřejné adresy IPv4 a pravidlo, které to dělá, je kratší, než většina lidí čeká. Nezáleží na syntaxi iptables, ale na stavu paketu, když dorazí do výstupního řetězce: zdrojová adresa tam stále musí klienty rozlišovat. Pokud dřívější maskování už oba sloučilo do jedné adresy, žádné pravidlo pro jednotlivého klienta tuto odlišnost neobnoví. Nejprve tuto otázku vyřešte, potom pište překlad.
Která identita přežije až k bráně
Pravidlo odpovídá zdrojové adrese paketu, ne uživatelskému jménu VPN ani názvu, který zobrazuje klientská aplikace. Vše, co paket přeloží dříve na cestě, určuje, co vaše pravidlo ještě může vidět. Spusťte tabulku nat v pořadí a najděte bod, kde je zdroj stále samostatný pro každého klienta.
iptables -t nat -S POSTROUTING
Přečtěte si ten výpis odshora. Pravidlo masquerade blízko vrcholu přepisuje zdroj pro každý odpovídající tok a položky pro jednotlivé klienty umístěné za ním odpovídají adrese, která už neexistuje. Když dva zařízení LAN sdílejí jeden tunel a přicházejí jako jediná vnitřní adresa, musí se změnit návrh dříve než firewall: udržte jejich zdrojové rozsahy oddělené nebo každému přidělte vlastní vnitřní adresu.
Přidělení vnitřní adresy svážete s ověřeným klientem. Předání této adresy jinému zařízení předává i výstupní politiku a překlad zdroje sám o sobě není důkazem identity.
Překlad nemůže vymyslet adresu
Každá veřejná adresa musí být přiřazena nebo směrována k tomuto výstupnímu bodu a odpovědi si musí najít cestu zpět. Pravidlo, které posílá provoz z adresy, na kterou nikdo nesměruje zpět, je na vzdáleném konci zahozeno nebo je odpovězeno hostiteli, který o to nikdy nežádal. Instance u poskytovatele cloudu obvykle překládá svou veřejnou adresu na adresu privátního rozhraní ještě předtím, než paket odejde, takže zdrojem SNAT musí být adresa, kterou poskytovatel přijme, ne hodnota, kterou ukazuje konzole. Přečtěte si model adres poskytovatele a řiďte se jím, místo abyste kopírovali veřejnou hodnotu do každého paketu.
V praxi to znamená zkontrolovat směrovaný prefix v konzoli poskytovatele, než se dotknete firewallu, a použít adresu privátního rozhraní jako zdroj překladu, když je mapování jedna ku jedné. Adresy použité v příkladech níže pocházejí z dokumentačních rozsahů, takže první věc, kterou je třeba nahradit, je samotný text adresy.
Vložte před obecný masquerade
Potvrďte výstupní rozhraní a aktuální řetězec, než cokoli přidáte. První určuje, kterým paketům může pravidlo odpovídat, a druhé ukazuje, co už před ním stojí.
ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers
První příkaz pojmenuje rozhraní, kterým paket na internet skutečně vychází. Druhý vypíše řetězec s čísly řádků. Obecná položka masquerade je řádek, nad kterým je třeba zůstat.
iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78
Dvě pravidla výše odpovídají každé jedné vnitřní adrese, omezují shodu na výstupní rozhraní a výslovně nastavují zdroj. Vkládejte, ne přidávejte: na pozici 1 se vyhodnocují před řádkem masquerade. Pořadí mezi nimi nehraje roli, protože se jejich zdroje liší. Nahraďte ens3 tím, co hlásil příkaz trasy, a držte ostatní správce firewallu mimo stejné háčky, protože dva nástroje zapisující jednu tabulku jsou obvyklým důvodem, proč správné pravidlo nemá účinek.
Dokažte zdroj novým tokem
Stavový NAT sváže překlad při zahájení toku a znovu jej použije pro další pakety, takže relace otevřená před změnou si po změně zachová svůj starý zdroj. Pravidlo dokáže jen nově navázané spojení.
conntrack -L -s 10.88.4.20 -p tcp --dport 443
Přečtěte si směr odpovědi tohoto záznamu: jeho cílem je adresa, kterou vzdálený konec vidí jako zdroj. Porovnejte ji s veřejnou adresou, kterou jste zamýšleli, a záznam nesoucí starou adresu berte jako důkaz toku, který začal příliš brzy, ne jako porouchané pravidlo. Požádejte klienta, aby otevřel nové spojení, a poté dotaz zopakujte. Vyprázdnění celé sledovací tabulky, aby se test vynutil, přeruší každou další relaci na bráně.
Překlad stále nevybírá trasu, nepropouští tok filtrem ani nezveřejňuje příchozí službu. Špatná trasa a chybějící povolovací pravidlo selhávají dál i po dokonalém pravidle SNAT. Zkontrolujte také IPv6 a jakoukoli sekundární výstupní cestu, potom si poznamenejte dvojice vnitřní-k-veřejnému do dokumentace firewallu, aby příští změna vycházela z mapování, a ne z textu pravidla.