AWS Client VPN ferbûn, mar EC2 reagearret noch altyd net

Myn laptop sei ferbûn. De AWS Client VPN-klant liet syn griene steat sjen, it endpoint registrearre in sesje, en dochs koe ik gjin MongoDB-poarte iepenje op in EC2-ynstânsje yn in privee-subnet. Neat wie fanselssprekkend stikken: it sertifikaat wie jildich, it profyl kaam út ’e console, en de tunnel ferfierde ferkear. De flater wie mines, want ik lies ferbûn as autorisearre.

Oanmelding beantwurdet krekt ien fraach: mei dizze identiteit in sesje opsette? Alles dêrnei wurdt besletten troch aparte regels dy’t jo sertifikaat nea sjogge. In sesje dy’t autentisearret en in pakket dat oankomt binne twa ferskate suksessen, en de kleau dêrtusken is wêr’t de measte rapporten fan it type de VPN is omheech mar de host is net berikber wenje.

De kontrôles hjirûnder binne de folchoarder dy’t ik no brûk.

Wat in ferbûne sesje echt bewiist

By de handshake falidearret it endpoint it klantsertifikaat tsjin syn trust store, of ferwiist de browser nei jo identity provider as SAML konfigurearre is. As dat slagget, kriget de klant in adres út ’e klant-CIDR fan it endpoint en de console lit in aktive ferbining sjen. Op gjin inkeld punt yn dy útwikseling freget eat oft jo 10.0.4.17 op poarte 27017 berikke meie.

Tastimming foar in bestimming is in apart objekt op it endpoint. Eltse flow wurdt tsjin de autorisasjeregels matche, en elk fan dy keppelt in bestimmings-CIDR oan ’e groep dêr’t de regel oan jûn is. As gjin regel de bestimming dekt, akseptearret it endpoint de sesje en smyt it ferkear fuort. D’r is gjin banner, gjin werferbiningslus en neat yn ’e klant-UI dat wegering seit.

Fergelykje de autorisasjeregel mei de boarne, net mei de VPC

Lis de regels op en hâld se njonken it adres dat de ynstânsje eins hat:

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

De útfier lit in bestimmings-CIDR en in groeps-ID per regel sjen. D’r binne twa flaters yn ferstoppe. De regel kin 10.0.0.0/16 autorisearje wylst de ynstânsje yn in peerde VPC op 10.1.0.0/16 sit; de peering-rûte bestiet, mar nimmen hat in autorisasjeregel foar it twadde berik skreau. Of de regel wiist nei in mapgroep dêr’t de brûker yn ’e map by heart, mar net yn ’e groep dy’t it endpoint evaluearret.

Skriuw de smelste regel dy’t de bestimming dekt, en foegje in twadde ta allinnich as in twadde CIDR echt nedich is. In brede 0.0.0.0/0-regel út in flugge start wurket, en dêrom oerlibbet er yn produksje en ferbergt it model.

Twa rûtetabellen beslute oft it pakket beweecht

In endpoint-rûte mapt in bestimmings-CIDR nei ien fan ’e subnetten dêr’t it endpoint mei ferbûn is. Dat is de helte fan in paad. De eigen rûtetabel fan it subnet moat noch altyd witte hoe it pakket foarút stjoerd wurde moat, en dat jildt op it stuit dat de bestimming efter in peering-ferbining, in transit gateway of in lokaal berik leit dat oer in site-to-site-tunnel berikber is.

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

Sykje in rûte wêrfan de bestimming mei de CIDR fan ’e boarne oerienkomt en wêrfan it doel in ferbûn subnet is. As de rûte mist, foegje dy ta. As er der is en de host bliuwt stil, dan leit de kleau oan ’e VPC-kant, fergelykje dan mei de rûtetabel fan it assosjaasjesubnet.

Ien ynstelling oan ’e klantkant brekt de rûtering sûnder de tunnel te brekken: in profyl dat route-nopull befettet. De rjochtline seit tsjin in OpenVPN-basearre klant om de rûtes te negearjen dy’t de server triuwt, sadat de interface allinnich mei it eigen adres fan it endpoint omheech komt en de bestimming gewoan gjin rûte hat. Kontrollearje mei ip route show op Linux of netstat -rn op macOS oft d’r in rûte fia de tun-interface is. Is dy der net, smyt dan route-nopull út it eksportearre profyl en ferbynje op ’e nij sadat de triuwde rûtes tapast wurde.

Befeiligingsgroepen sjogge jo klantadres net

Dit is it part dat ik in hiele middei ferkeard hie. Foar in IPv4-endpoint dat mei in subnet ferbûn is, fertaalt de tsjinst it boarne-adres fan ’e klant nei it adres fan ’e netwurkinterface fan it endpoint yn dat subnet. It pakket dat by de ynstânsje oankomt, draacht it adres net dat jo klant toande, dat in befeiligingsgroepregel dy’t de klantpool tastean, sis 172.16.0.0/22, matcht hielendal neat.

Stean de poarte ta fan ’e befeiligingsgroep fan it endpoint, dy’t oan ’e interface fan ’e assosjaasje fêst sit, ynstee fan fan ’e klant-CIDR. It ferwizen nei de groep is duorsumer as in adres hurdcodearje, want it interface-adres is net fan jo om te kontrolearjen. Netwurk-ACL’s binne steatleas, dus wêr’t eigen ynfier bestiet, moatte sawol de yngeande as de útgeande rjochting de flow tastean.

Ferbynje ek mei it privee-adres fan ’e ynstânsje. In iepenbier IP nimt it pakket út ’e VPC en werom der yn fia in oar paad mei oare regels, dus in iepenbiere test seit neat oer it privee paad.

In isolaasjefolchoarder dy’t by de earste flater stopt

Wurkje dizze yn folchoarder troch en stop wêr’t ien mislearret. Eltse stap slút ien laach út ynstee fan alle.

1. Befêstigje hokker identiteit de sesje brûkte en hokker groep it endpoint evaluearret. In sertifikaat út ien trust store is net deselde prinsipaal as in SAML-bewearing út ’e map.
2. Befêstigje dat in autorisasjeregel de CIDR fan ’e boarne foar dy groep dekt.
3. Befêstigje dat in endpoint-rûte bestiet en op in ferbûn subnet rjochte is, en dan dat de rûtetabel fan it subnet fierder foarút kin.
4. Befêstigje dat de befeiligingsgroep de poarte fan ’e endpoint-interface tastean, net fan ’e klantpool.
5. Testje fan binnen de VPC, mei in SSM-sesje op in oare ynstânsje yn itselde subnet, om in applikaasjeprobleem fan in klantpaadprobleem te skieden.

As de stappen net beslissend binne, is dizze tabel dêr’t ik op weromfal:

Twa akkountdetails produsearje symptomen dy’t op tastimmingsflaters lykje. Eltse brûker hat in apart klantsertifikaat nedich; ien diele oer twa masines lit de sesjes inoar ferkringe, en it resultaat is in werferbiningslus ynstee fan in wegering. As in nij endpoint oanmakke wurdt, lit de console in DNS-namme sjen dy’t guon klantferzjes allinnich akseptearje mei it tafallige foarheaksel dat op ’e endpoint-side stiet, dus kopiearje de folsleine namme ynstee fan dy te rekonstruearjen.

As stap fiif jo fêstset, helje dan it ferbiningslog fan it endpoint en lês de autorisaasje-ynfier foardat jo eat feroarje. It log neamt de bestimming dy’t kontrolearre is en de regel dy’t wol of net oerienkaam, en dat krimpt de fraach mei fjouwer lagen ta ien antwurd.