AWS Client VPN on ühendatud, aga EC2 ei vasta ikka

Minu sülearvuti näitas ühendatud. AWS Client VPN klient näitas rohelist olekut, endpoint logis sessiooni ja ikkagi ei saanud ma avada MongoDB porti EC2 instantsil privaatses alamvõrgus. Miski ei olnud ilmselgelt katki: sertifikaat oli kehtiv, profiil tuli konsoolist ja tunnel kandis liiklust. Viga oli minu, sest ma lugesin ühendatud tähenduses autoriseeritud.

Sisselogimine vastab täpselt ühele küsimusele: kas see identiteet tohib sessiooni luua? Kõike edasist otsustavad eraldi reeglid, mis ei näe kunagi sinu sertifikaati. Sessioon, mis autentib, ja pakett, mis kohale jõuab, on kaks erinevat õnnestumist, ja nende vaheline lünk on koht, kus elab enamik teatisi tüübis VPN on püsti, aga host pole kättesaadav.

Allolevad kontrollid on järjekord, mida ma praegu kasutan.

Mida ühendatud sessioon tegelikult tõestab

Kätlemise ajal valideerib endpoint kliendi sertifikaati oma trust store’i vastu või suunab brauseri sinu identiteedipakkuja juurde, kui SAML on seadistatud. Kui see läbib, saab klient aadressi endpointi kliendi CIDR-ist ja konsool näitab aktiivset ühendust. Ühelgi hetkel selles vahetuses ei küsita, kas sa võid jõuda aadressile 10.0.4.17 porti 27017 pidi.

Luba sihtkohale on endpointil eraldi objekt. Iga voog sobitatakse autoriseerimisreeglitega ja iga reegel seob sihtkoha CIDR-i grupiga, kellele reegel on antud. Kui ükski reegel sihtkohta ei kata, võtab endpoint sessiooni vastu ja viskab liikluse ära. Ei ole bännerit, ei ühenduse taastamise tsüklit ega midagi kliendi liideses, mis ütleks keelatud.

Võrdle autoriseerimisreeglit ressursiga, mitte VPC-ga

Loetle reeglid ja pane need selle aadressi kõrvale, mis instantsil tegelikult on:

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

Väljund näitab iga reegli kohta sihtkoha CIDR-i ja grupi ID-d. Sinna on peidetud kaks riket. Reegel võib autoriseerida 10.0.0.0/16, samal ajal kui instants asub peeritud VPC-s aadressil 10.1.0.0/16; peering-marsruut on olemas, aga keegi ei kirjutanud teise vahemiku jaoks autoriseerimisreeglit. Või osutab reegel kataloogigrupile, kuhu kasutaja kuulub kataloogis, aga mitte gruppi, mida endpoint hindab.

Kirjuta kitsaim reegel, mis sihtkoha katab, ja lisa teine ainult siis, kui teist CIDR-i on tõesti vaja. Kiirkäivitusest pärit lai reegel 0.0.0.0/0 töötab ja seepärast jääbki tootmisse ning varjab mudeli.

Kaks marsruuditabelit otsustavad, kas pakett liigub

Endpoint-marsruut kaardistab sihtkoha CIDR-i ühele alamvõrgule, millega endpoint on seotud. See on pool teest. Alamvõrgu enda marsruuditabel peab ikka teadma, kuidas paketti edasi saata, ja see loeb hetkel, mil sihtkoht on peering-ühenduse, transit gateway või kohapealse vahemiku taga, mis on kättesaadav site-to-site-tunneli kaudu.

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

Otsi marsruuti, mille sihtkoht vastab ressursi CIDR-ile ja mille sihtmärk on seotud alamvõrk. Kui marsruut puudub, lisa see. Kui see on olemas ja host on ikka vait, on lünk VPC poolel, seega võrdle seose alamvõrgu marsruuditabeliga.

Üks kliendipoolne seade rikub marsruutimise ilma tunnelit rikkumata: profiil, mis sisaldab route-nopull. Direktiiv ütleb OpenVPN-il põhinevale kliendile, et ignoreeriks marsruute, mida server lükkab, nii et liides tõuseb ainult endpointi enda aadressiga ja sihtkohal lihtsalt pole marsruuti. Kontrolli käsuga ip route show Linuxis või netstat -rn macOS-is, kas tun-liidese kaudu on marsruut olemas. Kui pole, eemalda route-nopull eksporditud profiilist ja ühendu uuesti, et lükatud marsruudid rakenduksid.

Turbegrupid ei näe sinu kliendi aadressi

See on osa, millega ma eksisin terve pärastlõuna. Alamvõrguga seotud IPv4-endpointi puhul tõlgib teenus kliendi lähteaadressi endpointi võrguliidese aadressiks selles alamvõrgus. Instantsini jõudev pakett ei kanna aadressi, mida sinu klient näitas, seega turbegrupi reegel, mis lubab kliendi pooli, ütleme 172.16.0.0/22, ei sobitu millegagi.

Luba port endpointi turbegrupist, mis on seotud seose liidesega, mitte kliendi CIDR-ist. Grupile viitamine on vastupidavam kui aadressi kõvakodeerimine, sest liidese aadress ei ole sinu kontrolli all. Võrgu ACL-id on olekuta, seega seal, kus on kohandatud kirjed, peavad nii sissetulev kui ka väljuv suund voogu lubama.

Ühenda ka instantsi privaatse aadressiga. Avalik IP viib paketi VPC-st välja ja toob teist teed mööda teiste reeglitega tagasi, seega avaliku aadressi test ei ütle privaatse tee kohta midagi.

Isolatsioonijärjekord, mis peatub esimese rikke juures

Käi need järjekorras läbi ja peatu seal, kus üks ebaõnnestub. Iga samm välistab ühe kihi, mitte kõik.

1. Kinnita, millist identiteeti sessioon kasutas ja millist gruppi endpoint hindab. Ühe trust store’i sertifikaat ei ole sama subjekt kui kataloogist pärit SAML-väide.
2. Kinnita, et autoriseerimisreegel katab selle grupi jaoks ressursi CIDR-i.
3. Kinnita, et endpoint-marsruut on olemas ja suunab seotud alamvõrku, seejärel et alamvõrgu marsruuditabel suudab edasi saata.
4. Kinnita, et turbegrupp lubab porti endpointi liidesest, mitte kliendi poolist.
5. Testi VPC seest, SSM-sessiooniga teisel instantsil samas alamvõrgus, et eraldada rakenduse probleem kliendi tee probleemist.

Kui sammud ei ole otsustavad, toetun sellele tabelile:

Kaks konto detaili tekitavad sümptomeid, mis näevad välja nagu õiguste rikked. Iga kasutaja vajab eraldi kliendi sertifikaati; ühe jagamine kahe masina vahel paneb sessioonid üksteist välja tõrjuma ja tulemuseks on ühenduse taastamise tsükkel, mitte keeldumine. Kui luuakse uus endpoint, näitab konsool DNS-nime, mida mõned kliendiversioonid aktsepteerivad ainult endpointi lehel näidatud juhusliku prefiksiga, seega kopeeri täisnimi, mitte ära rekonstrueeri seda.

Kui viies samm jätab sind kinni, tõmba endpointi ühenduslogi ja loe autoriseerimiskirjeid enne, kui midagi muudad. Logi nimetab kontrollitud sihtkoha ja reegli, mis sobis või ei sobinud, ning see taandab nelja kihiga küsimuse üheks vastuseks.