AWS Client VPN imeunganishwa lakini hakuna intaneti: ukaguzi wa njia

Umeunganishwa kwenye kituo cha mwisho cha AWS Client VPN, subneti ya kibinafsi inajibu, na bado kila ukurasa wa umma unaisha kwa muda kuisha. Mchanganyiko huo hupunguza tatizo hadi moja ya vitu vitatu upande unaosimamiwa: njia ambayo mteja husakinisha, njia ya kituo cha mwisho pamoja na kanuni yake ya idhini, au hatua inayofuata ya subneti iliyounganishwa. Ninazikagua kwa mpangilio huo kwa sababu kila kosa huonekana tofauti kwa upande wa mteja. Mwongozo huu unahusu kituo cha mwisho kinachosimamiwa kilichounganishwa na VPC, si seva ya OpenVPN kwenye EC2 na si muunganisho wa Cloud WAN au Transit Gateway.

Anza na kile ambacho mteja anaelekeza kweli

Hali ya kuunganishwa inathibitisha kipindi cha TLS na ugawaji wa CIDR kwa mteja, hakuna zaidi. Uliza mfumo wa uendeshaji anwani ya umma itaenda wapi wakati handaki iko juu. Kwenye Linux ip route get 1.1.1.1 inapaswa kutaja kiolesura cha handaki; kwenye macOS netstat -rn -f inet | head -5 huonyesha ingizo la chaguo-msingi; kwenye Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 huchapisha kiolesura kilichochaguliwa na hatua inayofuata.

Kisha soma bendera ya split-tunnel, kwa sababu huamua kama njia zilizochapishwa na kituo cha mwisho ni maeneo pekee ambayo mteja hutuma kwenye handaki:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Wakati SplitTunnel ni true, eneo la umma hutumia handaki tu wakati kituo cha mwisho kichapisha njia inayolifunika, kwa hivyo 0.0.0.0/0 iliyokosekana huacha trafiki hiyo kwenye kiolesura cha ndani. Ikiwa ni false, mteja hunasa trafiki, lakini kituo cha mwisho bado kinapaswa kuielekeza na kuidhinisha; vinginevyo pakiti zinaingia handakini na kusimama hapo. Unganisha tena mteja baada ya kubadilisha moja ya mipangilio miwili, kwa sababu njia na seva za DNS hutolewa wakati wa kuunganisha na mteja anayefanya kazi anaweza kubaki na seti ya zamani.

Soma njia ya kituo cha mwisho na kanuni ya idhini kwa tofauti

Hivi ni vitu viwili, na kuunda kimoja hakuundi kingine. Orodhesha njia za kituo cha mwisho na utafute njia ya chaguo-msingi ambayo lengo lake ni subneti iliyounganishwa:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Kila njia ina subneti moja ya lengo, kwa hivyo miunganisho mitatu inahitaji njia ya chaguo-msingi inayolingana kwa kila moja. AWS inaandika mahitaji haya ya ufunikaji, na dalili ya kimatendo ya pengo ni mtumiaji anayefanya kazi kutoka subneti moja na kukwama kutoka nyingine, jambo ambalo husomwa kama hitilafu ya vipindi badala ya njia iliyokosekana. Nyaraka rasmi za hali ya Client VPN zinaeleza mpangilio wa subneti ya umma ambao njia hizi zinahusiana nao.

Idhini ni kitu cha pili. Wakati hakuna kanuni inayofunika eneo la umma, handaki hubeba pakiti na huduma huitupa, kwa hivyo rasilimali za kibinafsi zinaendelea kufanya kazi wakati intaneti haifanyi:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Kanuni ya CIDR ya VPC haisemi chochote kuhusu 0.0.0.0/0. Kuongeza sehemu zilizokosekana kwa handaki kamili humaanisha njia moja kwa kila subneti iliyounganishwa pamoja na kanuni ya idhini unayoweza kukagua baadaye:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all hutoa lengo kwa kila mteja wa kituo cha mwisho, kwa hivyo ihifadhi tu wakati handaki inapaswa kuwa kamili; kanuni iliyofungwa kwa kikundi cha saraka ni bora unapokuwa na vikundi vya kufunga.

Fuatilia pakiti nje ya subneti iliyounganishwa

Njia ya kituo cha mwisho huamua kwamba AWS hukabidhi pakiti kwa subneti hiyo. Haiamui hatua inayofuata baada yake, ambayo huishi kwenye jedwali la njia la VPC la subneti yenyewe:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Njia ya chaguo-msingi inayoweza kutumika huelekeza kwenye lango la intaneti kwa subneti ya umma, au kwenye lango la NAT kwa ya kibinafsi, na hali blackhole inamaanisha lengo limefutwa na njia sasa inakufa kimya. Hizi ni majedwali tofauti na orodha ya njia za kituo cha mwisho, na kurekebisha moja hakurekebishi nyingine.

Kwenye hatua hii kuna vichujio viwili. Kikundi cha usalama kilichotumika kwenye muunganisho wa mtandao wa lengo lazima kiruhusu trafiki inayotoka kuelekea eneo la umma, na ACL yoyote ya mtandao inayotumika lazima iruhusu ombi na trafiki ya kurudi kwenye bandari za muda mfupi. Kikundi cha usalama cha muunganisho chenye vikwazo ni sababu ya kawaida kwa nini ufikiaji wa kibinafsi hufanya kazi na wa umma haufanyi.

Chagua tabaka la kwanza kutokana na dalili badala ya kubadilisha yote matatu kwa wakati mmoja:

Tenganisha hitilafu ya DNS na njia iliyokufa

Utatuzi wa majina hushindwa tofauti na upelekaji, na handaki kamili hufanya tofauti hiyo kuwa muhimu kwa sababu kitatuzi kilichosukumwa sasa kinafikiwa kupitia handaki. Ikiwa kituo cha mwisho kinabainisha seva za DNS za VPC, anwani zao zinahitaji ufunikaji wa njia na idhini kama eneo lingine lolote. Uliza kitatuzi moja kwa moja ili uone ni hitilafu gani unayo: dig +short example.com @10.0.0.2, au nslookup example.com 10.0.0.2 kwenye Windows.

Wakati URL ya nambari inajibu na ile yenye jina haijibu, acha kuhariri njia ya chaguo-msingi na fanya kazi kwenye DNS. Ombi kwa anwani ya IP halithibitishi chochote kuhusu mwenyeji pepe aliye na jina na cheti chake, kwa hivyo weka jaribio moja la jina katika ukaguzi wa mwisho.

Muda husaidia. Muunganisho wa TCP ambao haupati jibu ndani ya sekunde chache huelekeza kwenye uelekezaji au kichujio, wakati ombi linaloning'inia ndani ya utafutaji wa jina huelekeza kwenye kitatuzi. Kubadilisha njia ya chaguo-msingi wakati kitatuzi hakiwezi kufikiwa mara nyingi hufanya hitilafu moja kuwa mbili.

Rudisha kwa usafi, kisha thibitisha njia ya kutoka

Vitu vyote viwili vilikuwa vya kuongeza, kwa hivyo kurudisha ni kufuta na si kurekebisha:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Unganisha tena, kisha thibitisha ni njia ipi trafiki inatoka. Linganisha anwani ya umma iliyozingatiwa na anwani ya IP inayonyumbulika ya lango la NAT, au na lango la intaneti ulilokusudia kutumia, na uangalie kama rasilimali ya kibinafsi bado inajibu katika kipindi hicho hicho.

Maliza kwa orodha fupi, na chukulia kipengele cha mwisho kama sehemu ya mabadiliko na si nyaraka:

• Njia 0.0.0.0/0 moja ya kituo cha mwisho kwa kila subneti iliyounganishwa.
• Kanuni ya idhini inayofunika 0.0.0.0/0 kwa wateja unaotaka kuwahudumia.
• Njia ya chaguo-msingi ya VPC ambayo haiko katika hali ya blackhole kwenye kila subneti iliyounganishwa.
• Utokaji wa kikundi cha usalama cha muunganisho, pamoja na trafiki ya kurudi ya ACL.
• Anwani za kitatuzi zimeelekezwa na kuidhinishwa, zimethibitishwa kwa ombi la jina.
• Kurudisha kwa maandishi kwa njia na kanuni.

Kidokezo kimoja cha upeo: hii ni njia ya IPv4. Mteja wa rafu mbili huhifadhi muunganisho wa IPv6 aliokuwa nao, kwa hivyo njia ya chaguo-msingi ya IPv6 ni uamuzi tofauti na idhini yake mwenyewe, si athari ya pembeni ya hii.