IP klienta VPN v Kubernetes: zachovat, nebo SNAT?
Vyberte mezi zachováním skutečné adresy klienta VPN a zdrojovým NAT v Kubernetes pomocí tří podmínek, poté ověřte zpětnou cestu a obměnu podů.
Někde mezi tunelem a backendem adresa klienta buď přežije, nebo je nahrazena, a oba výsledky jsou obhajitelné. Volba patří vlastníkovi přijímající služby, ne tomu, kdo nainstaloval CNI. Když záleží na autorizaci po klientech, kvótách nebo auditních záznamech, musí adresa přežít každý skok. Když je sdílené připsání přijatelné, zdrojový NAT odstraní problém směrování, který byste jinak udržovali navěky.
Kde adresa klienta skutečně mizí
Paket vzdáleného klienta dorazí do podu VPN s vnitřním zdrojem v rozsahu tunelu, řekněme 10.90.0.42. Když pod tento paket předá dál směrem k ClusterIP nebo IP podu, mohou zdroj přepsat tři různé mechanismy. Pravidlo masquerade v CNI uzlu pokrývá provoz, který pod posílá mimo CIDR clusteru. conntrack záznam kube-proxy na cílovém uzlu pokrývá samotný skok na Service. Proxy, které spojení ukončí, paket vůbec nepředá, takže zdroj, který nakonec vidíte, patří proxy.
Každý žije v jiné vrstvě, a proto jedno pole Service téměř nikdy neopraví celou cestu.
externalTrafficPolicy na veřejném Service VPN rozhoduje jen o tom, co se stane s vnějším spojením: Local zachová vzdálenou adresu na uzlu, který ji přijal, zatímco Cluster nechá kube-proxy předat paket jinému uzlu a tam jej maskovat. Toto nastavení řídí listener, na který se vaši klienti připojují. Neříká nic o dešifrovaném paketu, který váš proces VPN poté směruje do clusteru.
Tři podmínky, které spor rozhodnou
Kladu stejné tři otázky ve stejném pořadí pokaždé, když se to objeví, protože první obvykle diskusi ukončí. Odpovězte na ně pro konkrétní zátěž, ne pro cluster jako celek. Dva clustery v jedné firmě mohou dojít k různým odpovědím a obě mohou být správné.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Pokud backend odpoví ano na první otázku a ne na druhou, máte práci na síti, ne manifest k úpravě. Pokud třetí řádek říká proxy, adresa nikdy neměla přežít, a předstírat opak stojí týden zachytávání paketů.
Co režim preserve vyžaduje od sítě
Zachovat zdroj znamená, že cílový uzel musí vracet provoz na 10.90.0.42 přes aktivní VPN gateway. Fond VPN není CIDR clusteru, takže ho žádné CNI ve výchozím nastavení nesměruje za vás. Přidáte trasu sami a poté zajistíte, aby koncový bod gateway, na který ukazuje, přežil přeplánování.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Další skok je adresa podu a adresy podů se pohybují. Nasměrujte trasu na VIP Service nebo na adresu uzlu, která zůstane na místě, nebo přijměte, že budete gateway honit po každém vyhoštění. Filtrování reverzní cesty je druhá past: striktní režim zahazuje pakety, jejichž zpětná cesta neodpovídá rozhraní, na kterém dorazily, což je přesně podoba zachovaného toku VPN.
Volná validace je často rozdíl mezi funkční zpětnou cestou a odpověďmi, které po opuštění backendu zmizí. Pravidla masquerade na uzlu VPN také musí vyloučit rozsah tunelu, jinak předaný paket odejde s adresou podu, bez ohledu na to, jakou trasu jste postavili. Vyjádřete toto vyloučení raději ve vlastní konfiguraci CNI než ruční úpravou iptables, protože agent při restartu přepisuje své řetězce a vaše ručně psané pravidlo přežije přesně do příštího upgradu.
NetworkPolicy je řízení přístupu, ne směrování. Zpřísnění politiky nikdy neobnoví adresu, kterou masquerade už nahradil.
Co SNAT stojí a jak to zapsat
Zdrojový NAT směrem do clusteru je levnější design a není to chyba. Backend vidí adresu podu nebo uzlu VPN, záznamy si navzájem odpovídají a nemusí existovat žádná zpětná trasa. Co ztratíte, je schopnost rozlišit dva klienty na síťové vrstvě, takže kvóty, zákazy a auditní stopy musí přijít odjinud.
Obvykle je tím odjinud aplikace: relační token, podepsaná hlavička nebo řádek protokolu PROXY, který zapisuje proxy, jež ovládáte. Ty dávají příjemci identitu, které může věřit jen tehdy, když proxy stojí v cestě a hlavičku nelze nastavit ze strany klienta. V runbooku výslovně uveďte, která platí, protože další inženýr bude předpokládat, že adresa v záznamu je klient. Není, a jeden incident stačí, aby byl tento předpoklad drahý.
Výměna zůstává poctivá, dokud je zapsaná.
Kontroly, které oddělí funkční cestu od šťastné
Testujte s novým spojením, ne s uloženým v cache, a testujte v obou směrech. Některé poruchy vypadají přerušovaně jen proto, že nové toky jdou přepsanou cestou.
Zachyťte tuple na třech místech během jednoho autorizovaného požadavku: hned po dekapsulaci, na výstupním rozhraní podu VPN a na backendu. Pokud se zdroj změní mezi druhým a třetím zachycením, příčina je po proudu od podu. Pokud se změní před druhým, překládá sám pod.
Poté pod VPN smažte a test zopakujte, zatímco se přeplánovává. Zachovaná cesta, která se při vyhoštění zlomí, je nedokončená, a stejně tak pravidlo NAT připnuté k adrese, která už neexistuje. Nakonec pošlete jeden požadavek ze zdroje, u kterého očekáváte odmítnutí, a potvrďte, že odmítnutí přichází z politiky, ne z chybějící trasy.