AWS Client VPN wedi cysylltu ond dim mynediad i’r rhyngrwyd: gwirio llwybrau

Rydych wedi cysylltu â phwynt terfyn AWS Client VPN, mae’r is-rwydwaith preifat yn ateb, ac mae pob tudalen gyhoeddus yn dal i amseru allan. Mae’r cyfuniad yna’n culhau’r broblem i un o dri gwrthrych ar yr ochr a reolir: y llwybr y mae’r cleient yn ei osod, llwybr y pwynt terfyn ynghyd â’i reol awdurdodi, neu naid nesaf yr is-rwydwaith gysylltiedig. Rwy’n eu gwirio yn y drefn honno oherwydd bod pob methiant yn edrych yn wahanol o safbwynt y cleient. Mae’r canllaw hwn yn ymdrin â’r pwynt terfyn a reolir sy’n gysylltiedig â VPC, nid gweinydd OpenVPN ar enghraifft EC2 ac nid atodiad Cloud WAN na Transit Gateway.

Dechreuwch gyda’r hyn y mae’r cleient yn ei lwybro mewn gwirionedd

Mae cyflwr cysylltiedig yn profi’r sesiwn TLS a’r neilltuo CIDR i’r cleient, dim mwy. Gofynnwch i’r system weithredu i ble byddai cyfeiriad cyhoeddus yn mynd tra bo’r twnnel i fyny. Ar Linux, ip route get 1.1.1.1 ddylai enwi rhyngwyneb y twnnel; ar macOS, netstat -rn -f inet | head -5 mae’r cofnod diofyn yn dangos; ar Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 mae’n argraffu’r rhyngwyneb a ddewiswyd a’r naid nesaf.

Yna darllenwch y faner twnnel hollt, oherwydd mae’n penderfynu ai llwybrau cyhoeddedig y pwynt terfyn yw’r unig gyrchfannau y mae’r cleient yn eu hanfon i’r twnnel:

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

Pan fo SplitTunnel yn true, dim ond pan fydd y pwynt terfyn yn cyhoeddi llwybr sy’n ei orchuddio y bydd cyrchfan gyhoeddus yn defnyddio’r twnnel, felly mae 0.0.0.0/0 ar goll yn gadael y traffig hwnnw ar y rhyngwyneb lleol. Pan fo’n false, mae’r cleient yn dal y traffig, ond rhaid i’r pwynt terfyn ei lwybro a’i awdurdodi o hyd; fel arall mae pecynnau’n mynd i’r twnnel ac yn stopio yno. Ailgysylltwch y cleient ar ôl newid y naill osodiad neu’r llall, oherwydd cyflwynir llwybrau a gweinyddwyr DNS adeg cysylltu a gall cleient sy’n rhedeg gadw’r set hen.

Darllenwch lwybr y pwynt terfyn a’r rheol awdurdodi ar wahân

Dau wrthrych yw’r rhain, ac nid yw creu un yn creu’r llall. Rhedwch restr o lwybrau’r pwynt terfyn a chwiliwch am lwybr diofyn y mae ei darged yn is-rwydwaith gysylltiedig:

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

Mae gan bob llwybr un is-rwydwaith darged yn union, felly mae angen llwybr diofyn cyfatebol ar bob un o’r tair cysylltiad. Mae AWS yn dogfennu’r gofyniad sylw hwn, ac arwydd ymarferol bwlch yw defnyddiwr sy’n gweithio o un is-rwydwaith ac yn stondio o un arall, sy’n darllen fel nam ysbeidiol yn lle llwybr ar goll. Mae’r dogfennau senario Client VPN swyddogol yn disgrifio’r trefniant is-rwydwaith cyhoeddus y mae’r llwybrau hyn yn perthyn iddo.

Awdurdodiad yw’r ail wrthrych. Pan nad oes rheol yn gorchuddio’r gyrchfan gyhoeddus, mae’r twnnel yn cario’r pecyn ac mae’r gwasanaeth yn ei ddileu, felly mae adnoddau preifat yn parhau i weithio tra nad yw’r rhyngrwyd yn gwneud:

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

Nid yw rheol ar gyfer CIDR y VPC yn dweud dim am 0.0.0.0/0. Mae ychwanegu’r darnau sydd ar goll ar gyfer twnnel llawn yn golygu un llwybr fesul is-rwydwaith gysylltiedig ynghyd â rheol awdurdodi y gallwch ei harchwilio’n ddiweddarach:

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 yn rhoi’r gyrchfan i bob cleient y pwynt terfyn, felly cadwch ef dim ond tra bo’r twnnel i fod yn llawn; mae rheol sy’n rhwym i grŵp cyfeiriadur yn well pan fydd gennych grwpiau i rwymo.

Dilynwch y pecyn allan o’r is-rwydwaith gysylltiedig

Mae llwybr y pwynt terfyn yn penderfynu bod AWS yn trosglwyddo’r pecyn i’r is-rwydwaith honno. Nid yw’n penderfynu’r naid nesaf y tu hwnt iddi, sy’n byw yn nhabl llwybrau VPC yr is-rwydwaith ei hun:

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

Mae llwybr diofyn defnyddiadwy yn pwyntio at giât ryngrwyd ar gyfer is-rwydwaith gyhoeddus, neu at giât NAT ar gyfer un breifat, ac mae cyflwr blackhole yn golygu bod y targed wedi’i ddileu a bod y llwybr bellach yn marw’n dawel. Mae’r rhain yn wahanol dabli i restr llwybrau’r pwynt terfyn, ac nid yw trwsio un yn trwsio’r llall.

Mae dau hidlydd ar y naid hon. Rhaid i’r grŵp diogelwch a gymhwysir i gysylltiad rhwydwaith y targed ganiatáu traffig allan tuag at y gyrchfan gyhoeddus, a rhaid i unrhyw ACL rhwydwaith berthnasol ganiatáu’r cais a’r traffig dychwelyd ar borthladdoedd efemeraidd. Mae grŵp diogelwch cysylltiad cyfyngus yn achos cyffredin pam mae mynediad preifat yn gweithio a chyhoeddus ddim.

Dewiswch yr haen gyntaf o’r symptom yn lle newid y tair ar unwaith:

Gwahanwch fethiant DNS oddi wrth lwybr marw

Mae datrys enwau’n methu’n wahanol i lawrgyfeirio, ac mae twnnel llawn yn gwneud y gwahaniaeth yn bwysig oherwydd bod y datryswr a wthiwyd bellach yn cael ei gyrraedd drwy’r twnnel. Os yw’r pwynt terfyn yn pennu gweinyddwyr DNS y VPC, mae angen sylw llwybr ac awdurdodiad ar eu cyfeiriadau fel unrhyw gyrchfan arall. Holwch y datryswr yn uniongyrchol i weld pa fethiant sydd gennych: dig +short example.com @10.0.0.2, neu nslookup example.com 10.0.0.2 ar Windows.

Pan fo URL rhifol yn ateb ac un enwog ddim, stopiwch olygu’r llwybr diofyn a gweithiwch ar DNS. Nid yw cais i gyfeiriad IP yn profi dim am westai rhithwir enwog a’i dystysgrif, felly cadwch un prawf enwog yn y gwiriad terfynol.

Mae amseru’n helpu. Mae cysylltiad TCP na chaiff ateb o fewn ychydig eiliadau’n pwyntio at lwybro neu hidlydd, tra bo cais sy’n hongian yng nghwiliad enw’n pwyntio at y datryswr. Mae newid y llwybr diofyn tra bo’r datryswr yn anhygyrraeddadwy’n tueddu i droi un methiant yn ddau.

Trowch yn ôl yn lân, yna gwiriwch y llwybr allanfa

Roedd y ddau wrthrych yn ychwanegiadol, felly dileu yw troi’n ôl, nid trwsio:

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

Ailgysylltwch, yna cadarnhewch pa lwybr y mae’r traffig yn ei adael. Cymharwch y cyfeiriad cyhoeddus a welwyd ag IP elastaidd y giât NAT, neu â’r giât ryngrwyd yr oeddech yn bwriadu ei defnyddio, a gwirio bod adnodd preifat yn dal i ateb yn yr un sesiwn.

Gorffennwch â rhestr fer, a thriniwch yr eitem olaf fel rhan o’r newid yn hytrach nag fel dogfennaeth:

• Un 0.0.0.0/0 llwybr pwynt terfyn ar gyfer pob is-rwydwaith gysylltiedig.
• Rheol awdurdodi sy’n gorchuddio 0.0.0.0/0 ar gyfer y cleientiaid rydych am eu gwasanaethu.
• Llwybr diofyn VPC nad yw’n blackhole ar bob is-rwydwaith gysylltiedig.
• Allanfa grŵp diogelwch y cysylltiad, ynghyd â thraffig dychwelyd ACL.
• Cyfeiriadau’r datryswr wedi’u llwybro a’u hawdurdodi, wedi’u gwirio â chais enwog.
• Troi’n ôl wedi’i gofnodi ar gyfer y llwybr a’r rheol.

Un nodyn cwmpas: llwybr IPv4 yw hwn. Mae cleient deu-stack yn cadw pa bynnag gysylltiad IPv6 sydd ganddo’n barod, felly mae llwybr diofyn IPv6 yn benderfyniad ar wahân â’i awdurdodiad ei hun yn hytrach nag yn sgil-effaith i hwn.