strongSwan na EC2: ať VPC směruje pracovní zátěž
Funkční tunel z brány dokazuje jen bránu. Nasměrujte podsíť pracovní zátěže, zapněte forwarding na hostu, rozšiřte selektory a pak to otestujte z ní.
Tunel běží, instance brány dokáže pingnout vzdálenou síť a instance aplikace vedle ní se nedostane nikam. Nic není rozbité. Test, který prošel, vznikl na VPN hostu a nikdy se neptal, zda tento host může přenést jinou zdrojovou adresu přes stejný vztah IPsec. Tento runbook tuto mezeru uzavírá ve čtyřech krocích, v pořadí, které udržuje každé selhání viditelné.
Nejprve si zapište čtyři adresy
Každý níže uvedený krok na ně odkazuje, takže je vyplňte pro svůj účet, než se dotknete směrovací tabulky.
VPC: 10.60.0.0/16
Gateway subnet: 10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network: 10.90.0.0/24
Příklad předpokládá schválené, funkční připojení IPsec založené na zásadách a tok zachovávající zdroj. Nejde o NATovaného klienta vzdáleného přístupu, který si půjčuje jednu přidělenou adresu, a tento rozdíl rozhoduje o tom, zda se selektory musí změnit.
Krok 1: dejte podsíti pracovní zátěže trasu
Směrovací tabulka, která je skutečně přidružená k podsíti pracovní zátěže, potřebuje cestu pro vzdálený prefix ukazující na síťové rozhraní brány. Trasa hosta nainstalovaná uvnitř instance není záznamem v této směrovací tabulce AWS a žádné množství konfigurace strongSwan ji nevytvoří.
AWS pokyny ke směrování přes zařízení popisují cíle síťového rozhraní a požadavek na kontrolu zdroje/cíle u instance, která předává provoz. Omezte tuto změnu kontroly na roli brány a běžné instance aplikací nechte být.
Nenahrazujte místní trasu VPC ani každý existující záznam, abyste uvolnili místo pro jednu schválenou síť. Zkontrolujte, co je přidružené a aktivní, ne to, co zobrazuje stránka konzole pro směrovací tabulku, kterou nikdo nepoužívá. Dvě tabulky, které vypadají stejně, mohou mít různá přidružení. Důležitá je ta, ke které je připojena podsíť pracovní zátěže.
Krok 2: zapněte forwarding na hostu
sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot
Jádro musí předávat a firewall hostu musí tranzit povolit. Přidejte zamýšlená pravidla předávání pro prefixy pracovní zátěže a vzdálené sítě místo toho, abyste přijali vše, a potvrďte, že podsíť brány si zachovává použitelnou transportní trasu pro svůj vlastní provoz.
Bezpečnostní skupiny jsou místem, kde tento krok obvykle uvízne. Prostředník nedědí chování odkazů na bezpečnostní skupiny přímé komunikace instancí, takže pravidlo zkopírované z příkladu spravovaného Client VPN nemusí nikdy odpovídat. Zkontrolujte bezpečnostní skupinu a ACL podsítě na skutečné cestě, v obou směrech.
Krok 3: rozšiřte selektory na skutečné zdroje
Zásada pokrývající na straně AWS pouze 10.60.1.10/32 vysvětluje úspěch vzniklý v bráně, aniž by pokrývala 10.60.2.20. Trasa ke vzdálenému cíli nerozšiřuje selektor provozu, a to je druhá polovina stejného překvapení.
swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors
Pokud dohodnutý návrh chrání celou VPC, oba partneři musí přijmout 10.60.0.0/16 a 10.90.0.0/24. Pokud chrání jednu pracovní zátěž, použijte tento užší prefix záměrně. V obou případech zkontrolujte nainstalovanou zásadu CHILD-SA, protože konfigurace, kterou jste upravili, a partner, který ji zúžil jinak, nejsou stejná dohoda.
Vzdálené pracoviště musí také směrovat odpovědi pro zachované zdroje VPC zpět přes zamýšlenou bránu IPsec. Zachovejte podporovanou výjimku z NAT pro chráněný provoz tam, kde existují jiná pravidla zdrojového NAT; překlad neschválené pracovní zátěže na povolenou adresu hosta je jiná smlouva o identitě, ne zkratka k přístupu, který jste chtěli.
Krok 4: ověřte a v případě potřeby vraťte zpět
Testujte z pracovní zátěže samotné novou povolenou operací aplikace, pak to zopakujte s cílem, který má být vyloučen. Zaznamenejte zdrojovou adresu, kterou vzdálená služba vidí, a zpětnou cestu, kterou používá. Ping na bránu nebo zelený stav IKE tímto testem není.
Pokud pracovní zátěž stále selhává, zatímco brána funguje, vracejte se po krocích v pořadí: selektor, pak forwarding a bezpečnostní skupiny, pak přidružená směrovací tabulka. Každý má jiný příznak a hádání přeskočí ten, který je skutečně špatně.
Vrácení zpět obrací stejné pořadí. Trasu podsítě pracovní zátěže odstraňte jako poslední, po obnovení předchozích selektorů, abyste nezanechali podsíť ukazující na bránu, která už nechrání její zdroje. Vlastní hosting může sloužit více než hostiteli brány, když tyto smlouvy platí, a AWS spravovaná Site-to-Site VPN je jiný provozní model, kde strongSwan může sedět na straně zákaznické brány.