AWS Client VPN gekoppel, maar EC2 kry steeds ’n timeout

My skootrekenaar het gekoppel gesê. Die AWS Client VPN-kliënt het sy groen toestand gewys, die endpoint het ’n sessie aangeteken, en ek kon steeds nie ’n MongoDB-poort op ’n EC2-instansie in ’n private subnet oopmaak nie. Niks was duidelik stukkend nie: die sertifikaat was geldig, die profiel het uit die console gekom, en die tonnel het verkeer gedra. Die fout was myne, want ek het gekoppel as gemagtig gelees.

Aanmelding beantwoord presies een vraag: mag hierdie identiteit ’n sessie vestig? Alles daarna word deur aparte reëls beslis wat jou sertifikaat nooit sien nie. ’n Sessie wat authentiseer en ’n pakkie wat aankom, is twee verskillende suksesse, en die gaping tussen hulle is waar die meeste verslae van die tipe die VPN is op maar die gasheer is onbereikbaar, woon.

Die kontroles hieronder is die volgorde wat ek nou gebruik.

Wat ’n gekoppelde sessie werklik bewys

Tydens die handshake valideer die endpoint die kliëntsertifikaat teen sy trust store, of herlei die blaaier na jou identity provider wanneer SAML opgestel is. As dit slaag, kry die kliënt ’n adres uit die endpoint se kliënt-CIDR en die console wys ’n aktiewe verbinding. Op geen punt in daardie uitruiling vra iets of jy 10.0.4.17 op poort 27017 mag bereik nie.

Toestemming vir ’n bestemming is ’n aparte objek op die endpoint. Elke vloei word teen die magtigingsreëls gepas, en elkeen paar ’n bestemmings-CIDR met die groep waaraan die reël toegestaan is. Wanneer geen reël die bestemming dek nie, aanvaar die endpoint die sessie en laat die verkeer val. Daar is geen banier, geen herverbindingsloop en niks in die kliënt-UI wat geweier sê nie.

Vergelyk die magtigingsreël met die bron, nie met die VPC nie

Lys die reëls en hou hulle langs die adres wat die instansie werklik het:

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

Die uitset wys ’n bestemmings-CIDR en ’n groep-ID per reël. Twee foute skuil daarin. Die reël mag 10.0.0.0/16 magtig terwyl die instansie in ’n gepeerde VPC op 10.1.0.0/16 sit; die peering-roete bestaan, maar niemand het ’n magtigingsreël vir die tweede reeks geskryf nie. Of die reël wys na ’n gidsgroep waarby die gebruiker in die gids aansluit, maar nie by die groep wat die endpoint evalueer nie.

Skryf die nouste reël wat die bestemming dek, en voeg ’n tweede by net wanneer ’n tweede CIDR werklik nodig is. ’n Breë 0.0.0.0/0-reël uit ’n quick start werk, en daarom oorleef dit tot in produksie en verberg die model.

Twee roetetabelle besluit of die pakkie beweeg

’n Endpoint-roete karteer ’n bestemmings-CIDR na een van die subnette waarmee die endpoint geassosieer is. Dit is die helfte van ’n pad. Die subnet se eie roetetabel moet steeds weet hoe om die pakkie aan te stuur, en dit maak saak die oomblik wanneer die bestemming agter ’n peering-verbinding, ’n transit gateway of ’n plaaslike reeks is wat oor ’n site-to-site-tonnel bereikbaar is.

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

Soek ’n roete wie se bestemming by die bron-CIDR pas en wie se teiken ’n geassosieerde subnet is. As die roete ontbreek, voeg dit by. As dit daar is en die gasheer is steeds stil, is die gaping aan die VPC-kant, so vergelyk met die roetetabel van die assosiasie-subnet.

Een kliënt-kant instelling breek roetering sonder om die tonnel te breek: ’n profiel wat route-nopull bevat. Die direktief sê vir ’n OpenVPN-gebaseerde kliënt om die roetes te ignoreer wat die bediener stoot, sodat die koppelvlak net met die endpoint se eie adres opkom en die bestemming bloot geen roete het nie. Kyk met ip route show op Linux of netstat -rn op macOS of daar ’n roete deur die tun-koppelvlak bestaan. As dit nie bestaan nie, verwyder route-nopull uit die uitgevoerde profiel en herverbind sodat die gestote roetes toegepas word.

Sekuriteitsgroepe sien nie jou kliëntadres nie

Dit is die deel wat ek ’n middag lank verkeerd gehad het. Vir ’n IPv4-endpoint wat met ’n subnet geassosieer is, vertaal die diens die kliënt se bronadres na die adres van die endpoint se netwerkkoppelvlak in daardie subnet. Die pakkie wat by die instansie aankom, dra nie die adres wat jou kliënt gewys het nie, so ’n sekuriteitsgroepreël wat die kliëntpoel toelaat, sê 172.16.0.0/22, pas op niks.

Laat die poort toe van die endpoint se sekuriteitsgroep, wat aan die assosiasie se koppelvlak geheg is, eerder as van die kliënt-CIDR. Om na die groep te verwys is duursamer as om ’n adres hard te kodeer, want die koppelvlakadres is nie joune om te beheer nie. Netwerk-ACL’s is staatloos, so waar pasgemaakte inskrywings bestaan, moet beide die inkomende en die uitgaande rigting die vloei toelaat.

Koppel ook aan die instansie se private adres. ’n Openbare IP neem die pakkie uit die VPC en terug in deur ’n ander pad met ander reëls, so ’n openbare toets sê niks oor die private pad nie.

’n Isoleringsorde wat by die eerste fout stop

Werk hierdie in volgorde deur en stop waar een faal. Elke stap skakel een laag uit eerder as almal.

1. Bevestig watter identiteit die sessie gebruik het en watter groep die endpoint evalueer. ’n Sertifikaat uit een trust store is nie dieselfde prinsipaal as ’n SAML-bewering uit die gids nie.
2. Bevestig dat ’n magtigingsreël die bron-CIDR vir daardie groep dek.
3. Bevestig dat ’n endpoint-roete bestaan en op ’n geassosieerde subnet gerig is, en bevestig dan dat die subnet se roetetabel verder kan stuur.
4. Bevestig dat die sekuriteitsgroep die poort van die endpoint-koppelvlak toelaat eerder as van die kliëntpoel.
5. Toets van binne die VPC, met ’n SSM-sessie op ’n ander instansie in dieselfde subnet, om ’n toepassingsprobleem van ’n kliëntpadprobleem te skei.

Wanneer die stappe nie beslissend is nie, is hierdie tabel waarop ek terugval:

Twee rekeningbesonderhede lewer simptome wat soos magtigingsfoute lyk. Elke gebruiker het ’n afsonderlike kliëntsertifikaat nodig; om een oor twee masjiene te deel laat die sessies mekaar verdring, en die resultaat is ’n herverbindingsloop eerder as ’n weiering. Wanneer ’n nuwe endpoint geskep word, wys die console ’n DNS-naam wat sommige kliëntweergawes net met die willekeurige voorvoegsel aanvaar wat op die endpoint-bladsy gewys word, so kopieer die volle naam eerder as om dit te herkonstrueer.

As stap vyf jou laat vashaak, haal die endpoint se verbindingslog en lees die magtigingsinskrywings voordat jy iets verander. Die log noem die bestemming wat nagegaan is en die reël wat gepas het of nie, wat die vraag met vier lae tot een antwoord verminder.