strongSwan az EC2-n: a VPC irányítsa a munkaterhelést

Az alagút él, az átjáró-példány pingelni tudja a távoli hálózatot, a mellette lévő alkalmazáspéldány viszont semmit sem ér el. Semmi sem romlott el. A sikeres teszt a VPN-gazdagépről indult, és soha nem kérdezte meg, hogy az a gazdagép át tud-e vinni egy másik forrás-címet ugyanazon az IPsec-kapcsolaton. Ez az útmutató négy lépésben zárja be ezt a rést, abban a sorrendben, amely minden hibát láthatóan tart.

Először írd fel a négy címet

Az alábbi lépések mindegyike ezekre hivatkozik, ezért töltsd ki őket a saját fiókodhoz, mielőtt hozzányúlsz egy útválasztási táblához.

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

A példa egy jóváhagyott, működő házirend-alapú IPsec-kapcsolatot és forrásmegőrző folyamot feltételez. Ez nem egy NAT-olt távelérési kliens, amely egy kiosztott címet kölcsönöz, és ez a különbség dönti el, hogy módosítani kell-e a szelektorokat.

1. lépés: adj útvonalat a munkaterhelés alhálózatának

A munkaterhelés alhálózatához ténylegesen hozzárendelt útválasztási táblának kell egy útvonal a távoli előtaghoz, amely az átjáró hálózati interfészére mutat. A példányon belül telepített vendég-útvonal nem bejegyzés abban az AWS-útválasztási táblában, és semmilyen mennyiségű strongSwan-konfiguráció nem hoz létre egyet.

Az AWS eszközön keresztüli útválasztási útmutatója leírja a hálózati interfész célokat és a továbbító példány forrás-/cél-ellenőrzési követelményét. Szűkítsd ezt az ellenőrzésváltozást az átjáró szerepkörére, és hagyd békén a közönséges alkalmazáspéldányokat.

Ne cseréld le a VPC helyi útvonalát vagy minden meglévő bejegyzést, hogy helyet csinálj egyetlen jóváhagyott hálózatnak. Vizsgáld meg, mi van hozzárendelve és aktív, ne azt, amit egy konzololdal mutat egy olyan útválasztási táblához, amelyet senki sem használ. Két hasonló táblának különböző hozzárendelései lehetnek. A fontos az, amelyhez a munkaterhelés alhálózata kapcsolódik.

2. lépés: engedélyezd a továbbítást a vendégen

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

A kernelnek továbbítania kell, a gazdagép tűzfalának pedig engedélyeznie kell az átjárást. Add hozzá a munkaterhelés- és távoli előtagokhoz szánt továbbítási szabályokat ahelyett, hogy mindent elfogadnál, és erősítsd meg, hogy az átjáró alhálózata használható átviteli útvonalat tart meg a saját forgalmához.

A biztonsági csoportok az a pont, ahol ez a lépés általában elakad. Egy köztes eszköz nem örökli a közvetlen példányok közötti kommunikáció biztonságicsoport-hivatkozási viselkedését, ezért egy kezelt Client VPN-példányból másolt szabály soha nem illeszkedhet. Ellenőrizd a biztonsági csoportot és az alhálózati ACL-t a tényleges útvonalon, mindkét irányban.

3. lépés: szélesítsd a szelektorokat a valódi forrásokra

Egy házirend, amely az AWS oldalon csak 10.60.1.10/32 címet fedi le, megmagyarázza az átjáróról induló sikert anélkül, hogy lefedné 10.60.2.20 címet. A távoli cél felé vezető útvonal nem szélesíti a forgalmi szelektort, és ez ugyanannak a meglepetésnek a második fele.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Ha a megbeszélt terv az egész VPC-t védi, mindkét félnek el kell fogadnia 10.60.0.0/16 és 10.90.0.0/24 címeket. Ha egyetlen munkaterhelést véd, használd szándékosan azt a szűkebb előtagot. Mindkét esetben vizsgáld meg a telepített CHILD-SA házirendet, mert a te általad szerkesztett konfiguráció és egy fél, amely másként szűkítette, nem ugyanaz a megállapodás.

A távoli helynek a megőrzött VPC-források válaszait is a szándékolt IPsec-átjárón keresztül kell visszairányítania. Tartsd meg a támogatott NAT-mentességet a védett forgalomhoz ott, ahol más forrás-NAT-szabályok vannak; egy nem jóváhagyott munkaterhelés engedélyezett gazdagépcímmé alakítása más identitásszerződés, nem rövidítés a kívánt hozzáféréshez.

4. lépés: ellenőrizd, majd szükség esetén állítsd vissza

Tesztelj a munkaterhelésről egy új, engedélyezett alkalmazásművelettel, majd ismételd meg egy kizárandó céllal. Jegyezd fel a forrás-címet, amelyet a távoli szolgáltatás lát, és a visszaútvonalat, amelyet használ. Az átjáró pingelése vagy a zöld IKE-állapot nem ez a teszt.

Ha a munkaterhelés továbbra is meghiúsul, miközben az átjáró működik, lépj vissza a lépéseken sorrendben: szelektor, majd továbbítás és biztonsági csoportok, majd a hozzárendelt útválasztási tábla. Mindegyiknek külön tünete van, és a találgatás kihagyja azt, amelyik valóban rossz.

A visszaállítás ugyanazt a sorrendet fordítja meg. A munkaterhelés alhálózatának útvonalát utolsóként távolítsd el, miután visszaállítottad a korábbi szelektorokat, hogy ne maradjon olyan alhálózat, amely egy olyan átjáróra mutat, amely már nem védi a forrásait. A saját üzemeltetés többet is kiszolgálhat, mint az átjáró-gazdagép, ha ezek a szerződések teljesülnek, az AWS által kezelt Site-to-Site VPN pedig más üzemeltetési modell, ahol a strongSwan az ügyfélátjáró oldalán is ülhet.