AWS Client VPN tengt en ekkert internetsamband: athugun á leiðum

Þú ert tengdur endapunkti AWS Client VPN, einkarekin undirnetið svarar, og samt renna allar opinberar síður út á tíma. Þessi samsetning þrengir vandamálið að einum af þremur hlutum á stjórnuðu hliðinni: leiðinni sem biðlarinn setur upp, leið endapunktsins ásamt heimildarreglu hans, eða næsta hoppi tengda undirnetsins. Ég athuga þau í þeirri röð vegna þess að hver bilun lítur öðruvísi út frá biðlaranum. Þessi leiðarvísir nær yfir stjórnaða endapunktinn sem er tengdur VPC, ekki OpenVPN netþjón á EC2 tilviki og ekki Cloud WAN eða Transit Gateway tengingu.

Byrjaðu á því sem biðlarinn beinir í raun

Tengd staða sannar TLS lotuna og CIDR úthlutunina til biðlarans, ekkert meira. Spurðu stýrikerfið hvert opinbert vistfang myndi fara meðan göngin eru uppi. Á Linux ætti ip route get 1.1.1.1 að nefna tengi ganganna; á macOS sýnir netstat -rn -f inet | head -5 sjálfgefna færslu; á Windows prentar Find-NetRoute -RemoteIPAddress 1.1.1.1 valið tengi og næsta hopp.

Lestu svo split-tunnel fánann, því hann ræður því hvort birtar leiðir endapunktsins séu einu áfangastaðirnir sem biðlarinn sendir inn í göngin:

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

Þegar SplitTunnel er true notar opinber áfangastaður göngin aðeins ef endapunkturinn birtir leið sem nær yfir hann, svo 0.0.0.0/0 sem vantar skilur þá umferð eftir á staðbundna tenginu. Þegar hann er false grípur biðlarinn umferðina, en endapunkturinn verður samt að beina henni og heimila; annars fara pakkar inn í göngin og stöðvast þar. Tengdu biðlarann aftur eftir að hafa breytt hvorri sem er stillingunni, því leiðir og DNS netþjónar eru afhentir við tengingu og keyrandi biðlari getur haldið gömlu safninu.

Lestu leið endapunktsins og heimildarregluna aðskilið

Þetta eru tveir hlutir, og að búa til annan býr ekki til hinn. Listaðu leiðir endapunktsins og leitaðu að sjálfgefinni leið þar sem markið er tengt undirnet:

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

Hver leið hefur nákvæmlega eitt markundirnet, svo þrjár tengingar þurfa samsvarandi sjálfgefna leið hver. AWS skjalfestir þessa yfirferðarkröfu, og hagnýtt einkenni eyðu er notandi sem vinnur frá einu undirneti og stöðvast frá öðru, sem les eins og slitrótt bilun frekar en leið sem vantar. Hin opinbera Client VPN aðstæðuskjöl lýsa fyrirkomulagi opinbers undirnets sem þessar leiðir tilheyra.

Heimild er annar hluturinn. Þegar engin regla nær yfir opinbera áfangastaðinn ber göngin pakkann og þjónustan hendir honum, svo einkaaðföng virka áfram meðan internetið gerir það ekki:

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

Regla fyrir CIDR VPC segir ekkert um 0.0.0.0/0. Að bæta við því sem vantar fyrir full göng þýðir eina leið fyrir hvert tengt undirnet auk heimildarreglu sem þú getur skoðað síðar:

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 veitir áfangastaðinn hverjum biðlara endapunktsins, svo hafðu hana aðeins meðan göngin eiga að vera full; regla bundin skráaskrá hópi er betri þegar þú hefur hópa til að binda.

Fylgdu pakkanum út úr tengda undirnetinu

Leið endapunktsins ræður því að AWS afhendir pakkann því undirneti. Hún ræður ekki næsta hoppi þar fyrir utan, sem býr í eigin VPC leiðatöflu undirnetsins:

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

Nýtanleg sjálfgefinn leið bendir á internetgátt fyrir opinbert undirnet, eða NAT gátt fyrir einkarekið, og staða blackhole þýðir að markinu var eytt og slóðin deyr nú hljóðlega. Þetta eru aðrar töflur en leiðalisti endapunktsins, og að laga aðra lagar ekki hina.

Á þessu hoppi sitja tveir síur. Öryggishópurinn sem er notaður á netkerfistengingu marksins verður að leyfa útleið umferð til opinbera áfangastaðarins, og hver sem er gildandi netkerfis-ACL verður að leyfa beiðnina og afturumferðina á skammtíma gáttum. Takmarkandi öryggishópur tengingarinnar er algeng ástæða þess að einkaaðgangur virkar en opinber ekki.

Veldu fyrsta lag út frá einkenninu í stað þess að breyta öllum þremur í einu:

Aðskilja DNS bilun frá dauðri leið

Nafnaupplausn bregst öðruvísi en framsending og full göng gera muninn mikilvægan því nú er náð í ýttu leysinn í gegnum göngin. Ef endapunkturinn tilgreinir VPC DNS netþjóna þurfa vistföng þeirra leiðaryfirferð og heimild eins og hver annar áfangastaður. Spurðu leysinn beint til að sjá hvaða bilun þú hefur: dig +short example.com @10.0.0.2, eða nslookup example.com 10.0.0.2 á Windows.

Þegar tölulegt URL svarar og nefnt ekki skaltu hætta að breyta sjálfgefnu leiðinni og vinna að DNS. Beiðni á IP vistfang sannar ekkert um nefndan sýndarþjón og skírteini hans, svo hafðu eina nefnda prófun í lokaatuguninni.

Tímasetning hjálpar. TCP tenging sem fær ekkert svar innan nokkurra sekúndna bendir á beiningu eða síu, meðan beiðni sem hangir í nafnaleit bendir á leysinn. Að breyta sjálfgefnu leiðinni meðan leysirinn er óaðgengilegur gerir oft eina bilun að tveimur.

Farðu hreint til baka og staðfestu svo útgönguslóðina

Báðir hlutir voru viðbætur, svo afturhvarf er eyðing, ekki viðgerð:

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

Tengdu aftur og staðfestu hvaða slóð umferðin fer út. Berðu saman sýnilegt opinbert vistfang við teygjanlegt IP vistfang NAT gáttarinnar, eða við internetgáttina sem þú ætlaðir að nota, og athugaðu að einkaaðfang svari enn í sama lotu.

Ljúktu með stuttum lista og meðhöndlaðu síðasta atriðið sem hluta breytingarinnar en ekki sem skjölun:

• Ein 0.0.0.0/0 leið endapunkts fyrir hvert tengt undirnet.
• Heimildarregla sem nær yfir 0.0.0.0/0 fyrir biðlarana sem þú vilt þjóna.
• Sjálfgefinn VPC leið sem er ekki í blackhole stöðu á hverju tengdu undirneti.
• Útgangur öryggishóps tengingarinnar, auk afturumferðar ACL.
• Vistföng leysisins beind og heimiluð, staðfest með nefndri beiðni.
• Skráð afturhvarf fyrir leiðina og regluna.

Ein umfangsathugasemd: þetta er IPv4 slóð. Tvískiptur biðlari heldur þeirri IPv6 tengingu sem hann hefur þegar, svo sjálfgefinn IPv6 leið er sérstök ákvörðun með eigin heimild og ekki aukaverkun þessarar.