AWS Client VPN imeunganishwa, lakini EC2 bado haijibu
Imeunganishwa inamaanisha tu kwamba cheti au kuingia kwa SAML kulifanya kazi. Sheria za idhini, njia za endpoint na vikundi vya usalama kila kimoja kinalinda sehemu ya njia kuelekea mwenyeji wa kibinafsi.
Laptop yangu ilionyesha imeunganishwa. Mteja wa AWS Client VPN ulionyesha hali yake ya kijani, endpoint ilirekodi kikao, na bado sikuweza kufungua bandari ya MongoDB kwenye EC2 instance katika subnet ya kibinafsi. Hakuna kitu kilichoonekana kimevunjika: cheti kilikuwa halali, profaili ilitoka kwenye konsoli, na handaki ilibeba trafiki. Hitilafu ilikuwa yangu, kwa sababu nilikuwa nikisoma imeunganishwa kama imeidhinishwa.
Kuingia hujibu swali moja hasa: je, utambulisho huu unaweza kuanzisha kikao? Kila kitu baada ya hapo huamuliwa na sheria tofauti ambazo hazioni cheti chako kamwe. Kikao kinachojithibitisha na pakiti inayowasili ni mafanikio mawili tofauti, na pengo kati yao ndilo mahali ambapo ripoti nyingi za aina ya VPN iko juu lakini mwenyeji hafikiwi huishi.
Ukaguzi ulio hapa chini ni mpangilio ninaotumia sasa.
Kikao kilichounganishwa kinathibitisha nini kwa kweli
Wakati wa handshake endpoint huthibitisha cheti cha mteja dhidi ya trust store yake, au huelekeza kivinjari kwa mtoa utambulisho wako wakati SAML imesanidiwa. Ikiwa hiyo itapita, mteja hupokea anwani kutoka CIDR ya mteja ya endpoint na konsoli huonyesha muunganisho hai. Hakuna mahali popote katika mabadilishano hayo panapouliza kama unaweza kufikia 10.0.4.17 kwenye bandari 27017.
Idhini ya kwenda mahali fulani ni kitu tofauti kwenye endpoint. Kila mtiririko hulinganishwa na sheria za idhini, na kila moja huunganisha CIDR ya lengwa na kundi ambalo sheria imepewa. Wakati hakuna sheria inayofunika lengwa, endpoint hukubali kikao na hutupa trafiki. Hakuna bango, hakuna mzunguko wa kuunganisha tena, na hakuna kitu kwenye kiolesura cha mteja kinachosema imekataliwa.
Linganisha sheria ya idhini na rasilimali, sio na VPC
Orodhesha sheria na uziweke kando ya anwani ambayo instance inayo kweli:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8Matokeo yanaonyesha CIDR ya lengwa na kitambulisho cha kundi kwa kila sheria. Kuna hitilafu mbili zilizofichwa ndani. Sheria inaweza kuidhinisha 10.0.0.0/16 wakati instance iko katika VPC iliyounganishwa kwa peering kwenye 10.1.0.0/16; njia ya peering ipo, lakini hakuna aliyeandika sheria ya idhini kwa masafa ya pili. Au sheria inaelekeza kwenye kundi la saraka ambalo mtumiaji ni mwanachama katika saraka lakini sio katika kundi ambalo endpoint hutathmini.
Andika sheria nyembamba zaidi inayofunika lengwa, na uongeze ya pili tu wakati CIDR ya pili inahitajika kweli. Sheria pana ya 0.0.0.0/0 kutoka mwanzo wa haraka inafanya kazi, na ndiyo sababu inaendelea hadi uzalishaji na kuficha modeli.
Majedwali mawili ya njia huamua kama pakiti itasonga
Njia ya endpoint huunganisha CIDR ya lengwa na moja ya subnet ambazo endpoint imeunganishwa nazo. Hiyo ni nusu ya njia. Jedwali la njia la subnet yenyewe bado linapaswa kujua jinsi ya kupeleka pakiti mbele, na hilo ni muhimu wakati lengwa liko nyuma ya muunganisho wa peering, transit gateway au masafa ya ndani yanayofikiwa kwa handaki ya site-to-site.
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8Tafuta njia ambayo lengwa lake linaendana na CIDR ya rasilimali na lengo lake ni subnet iliyounganishwa. Ikiwa njia haipo, iongeze. Ikiwa ipo na mwenyeji bado ni kimya, pengo liko upande wa VPC, kwa hiyo linganisha na jedwali la njia la subnet ya muunganisho.
Mpangilio mmoja upande wa mteja huvunja uelekezaji bila kuvunja handaki: profaili iliyo na route-nopull. Agizo hilo humwambia mteja anayetegemea OpenVPN kupuuza njia ambazo seva inasukuma, kwa hiyo kiolesura kinapanda na anwani ya endpoint yenyewe tu na lengwa halina njia kabisa. Angalia kwa ip route show kwenye Linux au netstat -rn kwenye macOS ikiwa kuna njia kupitia kiolesura cha tun. Ikiwa hakuna, ondoa route-nopull kwenye profaili iliyohamishwa na unganishe tena ili njia zilizosukumwa zitumike.
Vikundi vya usalama havioni anwani ya mteja wako
Hii ni sehemu niliyokosea kwa mchana mzima. Kwa endpoint ya IPv4 iliyounganishwa na subnet, huduma hutafsiri anwani ya chanzo ya mteja kuwa anwani ya kiolesura cha mtandao cha endpoint katika subnet hiyo. Pakiti inayowasili kwenye instance haibebi anwani ambayo mteja wako alionyesha, kwa hiyo sheria ya kundi la usalama inayoruhusu dimbwi la wateja, tuseme 172.16.0.0/22, hailingani na kitu chochote.
Ruhusu bandari kutoka kundi la usalama la endpoint, ambalo limeambatanishwa na kiolesura cha muunganisho, sio kutoka CIDR ya mteja. Kurejelea kundi ni endelevu zaidi kuliko kusimba anwani kwa nguvu, kwa sababu anwani ya kiolesura si yako kuidhibiti. ACL za mtandao hazina hali, kwa hiyo palipo na maingizo maalum, mwelekeo wa kuingia na wa kutoka wote unapaswa kuruhusu mtiririko.
Unganishe pia na anwani ya kibinafsi ya instance. IP ya umma huondoa pakiti nje ya VPC na kuirejesha ndani kwa njia nyingine yenye sheria nyingine, kwa hiyo jaribio la anwani ya umma halisemi chochote kuhusu njia ya kibinafsi.
Mpangilio wa kutenganisha unaosimama kwenye hitilafu ya kwanza
Pitia hizi kwa mpangilio na usimame pale moja inaposhindwa. Kila hatua huondoa safu moja, sio zote.
- Thibitisha ni utambulisho gani kikao kilitumia na ni kundi gani endpoint inatathmini. Cheti kutoka trust store moja sio mhusika yuleyule kama madai ya SAML kutoka saraka.
- Thibitisha kwamba sheria ya idhini inafunika CIDR ya rasilimali kwa kundi hilo.
- Thibitisha kwamba njia ya endpoint ipo na inaelekeza kwenye subnet iliyounganishwa, kisha kwamba jedwali la njia la subnet linaweza kupeleka mbele.
- Thibitisha kwamba kundi la usalama linaruhusu bandari kutoka kiolesura cha endpoint na sio kutoka dimbwi la wateja.
- Jaribu kutoka ndani ya VPC, kwa kikao cha SSM kwenye instance nyingine katika subnet hiyo hiyo, ili kutenganisha tatizo la programu na tatizo la njia ya mteja.
Wakati hatua haziamui, jedwali hili ndilo ninalotegemea:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
Maelezo mawili ya akaunti huzalisha dalili zinazoonekana kama kushindwa kwa idhini. Kila mtumiaji anahitaji cheti cha mteja tofauti; kushiriki kimoja kati ya mashine mbili hufanya vikao kusukana, na matokeo ni mzunguko wa kuunganisha tena badala ya kukataliwa. Wakati endpoint mpya inaundwa, konsoli huonyesha jina la DNS ambalo baadhi ya matoleo ya mteja hukubali tu na kiambishi cha nasibu kinachoonyeshwa kwenye ukurasa wa endpoint, kwa hiyo nakili jina kamili badala ya kulijenga upya.
Ikiwa hatua ya tano inakuzuia, vuta kumbukumbu ya miunganisho ya endpoint na usome maingizo ya idhini kabla ya kubadilisha chochote. Kumbukumbu hiyo hutaja lengwa lililokaguliwa na sheria iliyolingana au isiyolingana, na hiyo hupunguza swali la safu nne kuwa jibu moja.