Nakakonekta ang AWS Client VPN, pero hindi pa rin sumasagot ang EC2

Nagsabi ang laptop ko na nakakonekta. Ipinakita ng kliyente ng AWS Client VPN ang berdeng estado nito, nagtala ang endpoint ng sesyon, at hindi pa rin ako nakapagbukas ng port ng MongoDB sa isang instance ng EC2 sa pribadong subnet. Walang halatang sira: wasto ang sertipiko, galing sa console ang profile, at may dalang trapiko ang tunnel. Akin ang pagkakamali, dahil binabasa ko ang nakakonekta bilang awtorisado.

Ang pag-login ay sumasagot sa isang tanong lang: puwede bang magtatag ng sesyon ang pagkakakilanlang ito? Ang lahat pagkatapos nito ay pinagpapasyahan ng hiwalay na mga patakaran na hindi kailanman nakikita ang sertipiko mo. Ang sesyon na nagpapatunay at ang packet na dumarating ay dalawang magkaibang tagumpay, at ang puwang sa pagitan nila ang lugar kung saan nakatira ang karamihan ng ulat na uri ng naka-on ang VPN pero hindi maabot ang host.

Ang mga pagsusuri sa ibaba ang pagkakasunod-sunod na ginagamit ko ngayon.

Ano ang tunay na pinapatunayan ng nakakonektang sesyon

Sa handshake, binibigyang-katwiran ng endpoint ang sertipiko ng kliyente laban sa trust store nito, o inililipat ang browser sa tagapagbigay ng pagkakakilanlan mo kapag nakaayos ang SAML. Kung pumasa iyon, tumatanggap ang kliyente ng address mula sa client CIDR ng endpoint at nagpapakita ang console ng aktibong koneksyon. Sa anumang punto ng palitan na iyon, walang nagtatanong kung maaabot mo ang 10.0.4.17 sa port 27017.

Ang pahintulot para sa isang destinasyon ay hiwalay na bagay sa endpoint. Ang bawat daloy ay itinatapat sa mga patakaran ng awtorisasyon, at bawat isa ay nag-uugnay ng CIDR ng destinasyon sa pangkat na binibigyan ng patakaran. Kapag walang patakarang sumasaklaw sa destinasyon, tinatanggap ng endpoint ang sesyon at itinatapon ang trapiko. Walang banner, walang loop ng muling pagkonekta, at walang anuman sa interface ng kliyente na nagsasabing tinanggihan.

Ihambing ang patakaran ng awtorisasyon sa resource, hindi sa VPC

Ilista ang mga patakaran at ilagay ang mga ito sa tabi ng address na talagang mayroon ang instance:

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

Ipinapakita ng output ang CIDR ng destinasyon at ID ng pangkat sa bawat patakaran. May dalawang pagkabigo na nakatago roon. Maaaring awtorisahin ng patakaran ang 10.0.0.0/16 habang ang instance ay nasa peer na VPC sa 10.1.0.0/16; may ruta ng peering, pero walang sumulat ng patakaran ng awtorisasyon para sa ikalawang saklaw. O kaya'y tumuturo ang patakaran sa pangkat ng direktoryo na kinabibilangan ng gumagamit sa direktoryo pero hindi sa pangkat na tinatasa ng endpoint.

Isulat ang pinakamakitid na patakarang sumasaklaw sa destinasyon, at magdagdag ng pangalawa lamang kapag talagang kailangan ang ikalawang CIDR. Gumagana ang malawak na patakarang 0.0.0.0/0 mula sa mabilisang pagsisimula, at iyon ang dahilan kung bakit nakakaligtas ito hanggang produksyon at itinatago ang modelo.

Dalawang talahanayan ng ruta ang nagpapasya kung gagalaw ang packet

Ang ruta ng endpoint ay nag-uugnay ng CIDR ng destinasyon sa isa sa mga subnet na konektado ang endpoint. Kalahati iyon ng daan. Kailangan pa ring malaman ng sariling talahanayan ng ruta ng subnet kung paano ipagpapatuloy ang packet, at mahalaga iyon sa sandaling nasa likod ng koneksyon ng peering, transit gateway o saklaw na on-premises na maabot sa tunnel na site-to-site ang destinasyon.

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

Maghanap ng rutang tumutugma ang destinasyon sa CIDR ng resource at ang target ay konektadong subnet. Kung wala ang ruta, idagdag ito. Kung mayroon at tahimik pa rin ang host, nasa panig ng VPC ang puwang, kaya ihambing sa talahanayan ng ruta ng subnet ng asosasyon.

Isang setting sa panig ng kliyente ang sumisira sa routing nang hindi sinisira ang tunnel: isang profile na may route-nopull. Sinasabi ng direktiba sa kliyenteng nakabatay sa OpenVPN na huwag pansinin ang mga rutang itinutulak ng server, kaya ang interface ay bubukas na may address ng endpoint lamang at wala talagang ruta ang destinasyon. Suriin gamit ang ip route show sa Linux o netstat -rn sa macOS kung may ruta sa interface ng tun. Kung wala, alisin ang route-nopull sa na-export na profile at kumonekta muli upang mailapat ang mga itinulak na ruta.

Hindi nakikita ng mga pangkat ng seguridad ang address ng kliyente mo

Ito ang bahaging mali ako nang isang buong hapon. Para sa endpoint na IPv4 na konektado sa subnet, isinasalin ng serbisyo ang source address ng kliyente sa address ng interface ng network ng endpoint sa subnet na iyon. Ang packet na dumarating sa instance ay hindi nagdadala ng address na ipinakita ng kliyente mo, kaya ang patakaran ng pangkat ng seguridad na pumapayag sa pool ng kliyente, sabihin nating 172.16.0.0/22, ay walang katugmang anuman.

Payagan ang port mula sa pangkat ng seguridad ng endpoint, na nakakabit sa interface ng asosasyon, hindi mula sa CIDR ng kliyente. Mas matibay ang pagtukoy sa pangkat kaysa sa hard-coded na address, dahil ang address ng interface ay hindi sa iyo upang kontrolin. Ang mga ACL ng network ay walang estado, kaya saan may mga pasadyang entry, kailangang payagan ng papasok at palabas na direksyon ang daloy.

Kumonekta rin sa pribadong address ng instance. Ang pampublikong IP ay naglalabas ng packet mula sa VPC at nagpapasok muli sa ibang daan na may ibang patakaran, kaya ang pagsubok sa pampublikong address ay walang sinasabi tungkol sa pribadong daan.

Isang pagkakasunod-sunod ng paghiwalay na tumitigil sa unang pagkabigo

Daanan ang mga ito nang sunod-sunod at tumigil kung saan nabigo ang isa. Ang bawat hakbang ay nag-aalis ng isang patong, hindi lahat.

1. Tiyakin kung anong pagkakakilanlan ang ginamit ng sesyon at anong pangkat ang tinatasa ng endpoint. Ang sertipiko mula sa isang trust store ay hindi kaparehong principal ng isang pahayag ng SAML mula sa direktoryo.
2. Tiyakin na sinasaklaw ng patakaran ng awtorisasyon ang CIDR ng resource para sa pangkat na iyon.
3. Tiyakin na may ruta ng endpoint at nakaturo ito sa konektadong subnet, pagkatapos ay na maipagpapatuloy ng talahanayan ng ruta ng subnet.
4. Tiyakin na pinapayagan ng pangkat ng seguridad ang port mula sa interface ng endpoint at hindi mula sa pool ng kliyente.
5. Subukan mula sa loob ng VPC, gamit ang sesyon ng SSM sa ibang instance sa parehong subnet, upang ihiwalay ang problema ng aplikasyon sa problema ng daan ng kliyente.

Kapag hindi mapagpasyahan ang mga hakbang, ito ang talahanayang sinasandigan ko:

Dalawang detalye ng account ang lumilikha ng mga sintomas na parang pagkabigo ng pahintulot. Kailangan ng bawat gumagamit ng hiwalay na sertipiko ng kliyente; ang pagbabahagi ng isa sa dalawang makina ay nagtutulakan ang mga sesyon, at ang resulta ay loop ng muling pagkonekta, hindi pagtanggi. Kapag may bagong endpoint, nagpapakita ang console ng pangalan ng DNS na tinatanggap lamang ng ilang bersyon ng kliyente kapag may random na prefix na nakalathala sa pahina ng endpoint, kaya kopyahin ang buong pangalan sa halip na buuin muli.

Kung mabara ka ng ikalimang hakbang, kunin ang log ng koneksyon ng endpoint at basahin ang mga entry ng awtorisasyon bago magbago ng anuman. Pinapangalanan ng log ang sinuring destinasyon at ang patakarang tumugma o hindi, at iyon ay nagpapaikli sa tanong na may apat na patong tungo sa isang sagot.