Az AWS Client VPN csatlakozik, az EC2 mégis válasz nélkül marad

A laptopom azt mutatta, hogy csatlakozva. Az AWS Client VPN kliens a zöld állapotát mutatta, az endpoint naplózott egy munkamenetet, és mégsem tudtam megnyitni egy MongoDB-portot egy EC2-példányon egy privát alhálózatban. Semmi nem volt láthatóan elromolva: a tanúsítvány érvényes volt, a profil a konzolból jött, és az alagút szállította a forgalmat. A hiba az enyém volt, mert a csatlakozva szót engedélyezettként olvastam.

A bejelentkezés pontosan egy kérdésre válaszol: létesíthet-e ez az identitás munkamenetet? Minden továbbit külön szabályok döntenek el, amelyek soha nem látják a tanúsítványodat. A munkamenet, amely hitelesít, és a csomag, amely megérkezik, két különböző siker, és a kettő közötti résben él a legtöbb olyan bejelentés, hogy a VPN áll, de a hoszt nem érhető el.

Az alábbi ellenőrzések az a sorrend, amelyet most használok.

Mit bizonyít valójában egy csatlakozott munkamenet

A handshake során az endpoint a kliens tanúsítványát a saját trust store-jával ellenőrzi, vagy átirányítja a böngészőt az identitásszolgáltatódhoz, ha a SAML be van állítva. Ha ez átmegy, a kliens címet kap az endpoint kliens-CIDR-jéből, és a konzol aktív kapcsolatot mutat. A váltás egyetlen pontján sem kérdezi semmi, hogy elérheted-e a 10.0.4.17-et a 27017-es porton.

Egy cél engedélyezése külön objektum az endpointon. Minden folyamot az engedélyezési szabályokhoz mérünk, és mindegyik egy cél-CIDR-t párosít azzal a csoporttal, amelynek a szabályt adják. Amikor egyetlen szabály sem fedi a célt, az endpoint elfogadja a munkamenetet és eldobja a forgalmat. Nincs szalaghirdetés, nincs újracsatlakozási hurok, és semmi a kliens felületén, ami azt írná: megtagadva.

Az engedélyezési szabályt az erőforráshoz hasonlítsd, ne a VPC-hez

Listázd a szabályokat, és tedd őket annak a címnek a mellé, amely a példánynak valóban van:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

A kimenet szabályonként egy cél-CIDR-t és egy csoport-azonosítót mutat. Két hiba rejtőzik benne. A szabály engedélyezheti a 10.0.0.0/16-ot, miközben a példány egy peeringelt VPC-ben, a 10.1.0.0/16-on ül; a peering-útvonal létezik, de senki nem írt engedélyezési szabályt a második tartományra. Vagy a szabály egy olyan címtár-csoportra mutat, amelynek a felhasználó tagja a címtárban, de abban a csoportban nem, amelyet az endpoint értékel.

Írd meg a legszűkebb szabályt, amely fedi a célt, és csak akkor adj hozzá egy másodikat, ha egy második CIDR valóban szükséges. Egy gyors indításból származó széles 0.0.0.0/0 szabály működik, és éppen ezért éli túl a termelésig, és rejti el a modellt.

Két útvonaltábla dönti el, mozdul-e a csomag

Az endpoint-útvonal egy cél-CIDR-t rendel az endpointtal társított alhálózatok egyikéhez. Ez az út fele. Az alhálózat saját útvonaltáblájának még mindig tudnia kell, hogyan továbbítsa a csomagot, és ez abban a pillanatban számít, amikor a cél egy peering-kapcsolat, egy tranzitátjáró vagy egy telephelyi tartomány mögött van, amely site-to-site alagúton keresztül érhető el.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Keress olyan útvonalat, amelynek célja megegyezik az erőforrás CIDR-jével, és amelynek célpontja egy társított alhálózat. Ha hiányzik az útvonal, add hozzá. Ha megvan, és a hoszt továbbra is hallgat, a rés a VPC oldalán van, ezért hasonlítsd össze a társítási alhálózat útvonaltáblájával.

Egy kliensoldali beállítás elrontja az útválasztást anélkül, hogy elrontaná az alagutat: egy route-nopull-t tartalmazó profil. Az utasítás azt mondja a OpenVPN-alapú kliensnek, hogy hagyja figyelmen kívül a szerver által tolt útvonalakat, így az interfész csak az endpoint saját címével jön fel, és a célnak egyszerűen nincs útvonala. Ellenőrizd ip route show-val Linuxon vagy netstat -rn-nel macOS-en, hogy létezik-e útvonal a tun interfészen keresztül. Ha nem, vedd ki a route-nopull-t az exportált profilból, és csatlakozz újra, hogy a tolt útvonalak érvénybe lépjenek.

A biztonsági csoportok nem látják a kliensed címét

Ez az a rész, amit egy egész délután rosszul tudtam. Egy alhálózathoz társított IPv4-endpoint esetén a szolgáltatás a kliens forráscímét az endpoint hálózati interfészének címére fordítja abban az alhálózatban. A példányhoz érkező csomag nem a kliensed által mutatott címet hordozza, ezért a klienspoolt, mondjuk a 172.16.0.0/22-t engedélyező biztonsági csoportszabály semmivel sem találkozik.

A portot az endpoint biztonsági csoportjából engedélyezd, amely a társítás interfészéhez van csatolva, ne a kliens-CIDR-ből. A csoportra hivatkozni tartósabb, mint egy címet beégetni, mert az interfész címe nem a te irányításod alatt áll. A hálózati ACL-ek állapot nélküliek, ezért ahol egyedi bejegyzések vannak, ott a bejövő és a kimenő iránynak is engedélyeznie kell a folyamot.

Csatlakozz a példány privát címéhez is. Egy nyilvános IP kiviszi a csomagot a VPC-ből, és egy másik útvonalon, más szabályokkal hozza vissza, ezért egy nyilvános címre végzett teszt semmit sem mond a privát útvonalról.

Elszigetelési sorrend, amely az első hibánál megáll

Ezeket sorrendben végezd el, és állj meg ott, ahol egy elbukik. Minden lépés egy réteget zár ki, nem az összeset.

1. Erősítsd meg, melyik identitást használta a munkamenet, és melyik csoportot értékeli az endpoint. Az egyik trust store-ból származó tanúsítvány nem ugyanaz a főszereplő, mint a címtárból érkező SAML-állítás.
2. Erősítsd meg, hogy egy engedélyezési szabály fedi az erőforrás CIDR-jét arra a csoportra.
3. Erősítsd meg, hogy létezik endpoint-útvonal, és társított alhálózatra mutat, majd azt, hogy az alhálózat útvonaltáblája tovább tud küldeni.
4. Erősítsd meg, hogy a biztonsági csoport a portot az endpoint interfészéről engedélyezi, nem a klienspoolból.
5. Tesztelj a VPC-n belülről, egy SSM-munkamenettel egy másik példányon ugyanabban az alhálózatban, hogy elválaszd az alkalmazásproblémát a kliensútvonal-problémától.

Amikor a lépések nem döntenek, erre a táblázatra támaszkodom:

Két fiókadat olyan tüneteket okoz, amelyek engedélyezési hibáknak látszanak. Minden felhasználónak külön kliens-tanúsítvány kell; egyet két gépen megosztva a munkamenetek kiszorítják egymást, és az eredmény újracsatlakozási hurok, nem elutasítás. Amikor új endpoint jön létre, a konzol egy DNS-nevet mutat, amelyet egyes klienverziók csak az endpoint oldalán látható véletlen előtaggal fogadnak el, ezért másold a teljes nevet ahelyett, hogy újraépítenéd.

Ha az ötödik lépés elakaszt, húzd le az endpoint kapcsolati naplóját, és olvasd el az engedélyezési bejegyzéseket, mielőtt bármit módosítanál. A napló megnevezi az ellenőrzött célt és a szabályt, amely egyezett vagy nem, és ez a négyrétegű kérdést egyetlen válaszra szűkíti.