Zachovat IP adresy VPN klientů, nebo je na hranici cloudu přeložit pomocí SNAT
Zachování zdroje drží identitu klienta v každém záznamu, SNAT drží směrovací tabulku malou. Tři podmínky řeknou, co aplikace potřebuje.
Zachování adresy VPN klienta až k aplikaci způsobí, že každý řádek logu a každý záznam v seznamu povolených znamená totéž. Přepsání adresy na okraji cloudu zjednoduší směrovací tabulku a udělá logy méně užitečnými. Ani jedna volba není sama o sobě špatná a argument, který ji rozhoduje, se málokdy týká výkonu. Rozhodují tři podmínky: zda aplikace musí vědět, který člověk se připojil, zda cloudová tkanina přijme zdroj, který hodláte odeslat, a kdo je ochoten se potom ujmout zpětné trasy.
Rozhodují tři podmínky
Začněte požadavkem aplikace, ne síťovým diagramem. Pokud autorizace nebo audit závisí na individuální adrese klienta, je její zachování funkčním požadavkem a překlad regresí. Pokud aplikace potřebuje vědět jen to, že provoz dorazil cestou vzdáleného přístupu, přeložená adresa stačí a je mnohem levnější na provoz.
Druhá podmínka je mechanická. Virtuální síť automaticky nevěří paketu, který tvrdí adresu, jež nebyla přiřazena odesílajícímu rozhraní. Většina cloudových tkanin to vynucuje, různými způsoby a pod různými jmény, a návrh, který to ignoruje, bude na diagramu vypadat správně a v produkci tiše zahazovat.
Třetí je organizační. Zachování zdrojů znamená, že směrovací tabulka podsítě aplikace musí pro prefix klienta ukazovat zpět na bránu, a každý tým, který později přidá podsíť, musí tuto trasu udržet konzistentní. To je jednorázově malá cena a opakující se cena napříč desítkami účtů. Rozhodněte, kdo ji zaplatí, než chování slíbíte.
Trasa není povolení ke spoofingu
Přidání zpětné trasy řekne vaší podsíti, kam mají odpovědi jít. Neřekne tkanině, že instance, která tyto pakety předává, je smí odesílat s cizím zdrojem. V AWS je příslušnou kontrolou ověření zdroje a cíle a je vidět u každé instance:
aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
--query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
--no-source-dest-check
Vypněte ji jen u instance, jejíž dokumentovanou prací je předávání, a u ničeho jiného. Každá VM aplikace, která kontrolu nechá zapnutou, je o jeden stroj méně, který lze použít k odesílání provozu s vypůjčeným zdrojem. Pokud vaše platforma není AWS, hledejte odpovídající nastavení anti-spoofingu nebo povolených adres, místo abyste předpokládali, že se chování přenese.
Rychlý odchyt paketů vyřeší otázku rychleji než čtení konzole. Pokud odpovědi odejdou a klient je nikdy nevidí, tkanina zahazuje podvržený zdroj, a ne že by aplikace selhávala.
Co překlad kupuje a co stojí
Přepsání zdroje na bráně odstraní problém zpětné cesty. Aplikace vidí jednu adresu, kterou už umí dosáhnout, a prefix klienta se nikdy nemusí objevit ve směrovací tabulce cloudu. V Linuxu je pravidlo jeden řádek a stojí za to napsat nejužší verzi, kterou zvládnete:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10
Všimněte si, co aplikace nyní zaznamenává: 10.40.3.10 pro každého uživatele, při každém spojení, navždy. Jakýkoli seznam povolených adres postavený na této hodnotě nyní uděluje přístup celé populaci vzdáleného přístupu a každé vyšetřování incidentu se musí vrátit k bráně, aby odpovědělo, kdo to byl.
Řešením není vzdát se překladu, ale přestat předstírat, že adresa je identita. Neste identitu klienta v autentizovaném poli, zaznamenejte ji na bráně spolu s přeloženou n-ticí a nechte aplikaci se na ni připojit. Bez spojovacího klíče mění překlad síťový problém v trvalý forenzní.
Relé je jiné rozhraní
Reverzní proxy před aplikací otázku směrované cesty úplně obchází. Proxy otevírá vlastní spojení k backendu, takže prefix klienta nemusí být uvnitř virtuální sítě nikdy směrovatelný a aplikace může přijmout identitu v hlavičce, kterou proxy nastaví.
Tato hlavička je důvěryhodná jen tehdy, když ji backend přijímá od proxy a od ničeho jiného. V terminologii nginx to znamená výslovně pojmenovat důvěryhodného partnera, místo abyste věřili všemu, co dorazí:
set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
Každý klient, který se k backendu dostane přímo, může stejnou hlavičku zfalšovat, takže backend musí být nedostupný jinak než přes proxy. To je fakt o firewallu, ne názor na konfiguraci, a právě tento předpoklad lidé při kopírování úryvku vynechají.
Relé také mění to, co kupujete. Získáte identitu na úrovni aplikace a přirozené místo, kde ji zaznamenat; vzdáte se obecnosti, protože každý nový protokol potřebuje vlastní podporu proxy. Pro služby HTTP je tato výměna obvykle dobrá a pro cokoli, co HTTP není, obvykle vůbec není k dispozici.
Zapište, co každá hranice vidí
Ať zvolíte cokoli, návrhová revize by měla skončit jednou tabulkou, která pojmenuje zdrojovou adresu a prokazatelnou identitu na každém skoku. Bez ní první incident vytvoří tři týmy, z nichž každý popisuje jiného klienta.
| Boundary | Source the next hop sees | What is actually proven |
|---|---|---|
| Client to gateway | 172.20.8.14 | A certificate or credential was presented |
| Gateway to app subnet, preserved | 172.20.8.14 | The same session, if the return route exists |
| Gateway to app subnet, translated | 10.40.3.10 | Only that traffic came through the gateway |
| Proxy to backend | 10.40.3.10 plus a header | The proxy asserted an identity it authenticated |
Pak volejte. Zachovejte zdroj, když autorizace aplikace skutečně závisí na adrese klienta a můžete se ujmout trasy. Překládejte, když tomu tak není a identitu můžete nést mimo pásmo, a pro nastavení předávání specifická pro platformu použijte pokyny AWS pro instance předávání. Sáhněte po relé, když služba mluví HTTP a chcete, aby identita přestala být adresou.