AWS Client VPN csatlakozva, de nincs internet: útvonalak ellenőrzése

Csatlakozva van az AWS Client VPN végpontjához, a privát alhálózat válaszol, és mégis minden nyilvános oldal időtúllépéssel végződik. Ez a kombináció a felügyelt oldal három objektumának egyikére szűkíti a problémát: a kliens által telepített útvonalra, a végpont útvonalára az engedélyezési szabályával együtt, vagy a kapcsolódó alhálózat következő ugrására. Ebben a sorrendben ellenőrzöm őket, mert minden hiba másképp néz ki a kliens oldaláról. Ez az útmutató a VPC-hez kapcsolódó felügyelt végponttal foglalkozik, nem egy EC2-példányon futó OpenVPN-kiszolgálóval és nem Cloud WAN vagy Transit Gateway kapcsolattal.

Kezdje azzal, mit irányít valójában a kliens

A csatlakozott állapot a TLS-munkamenetet és a kliens CIDR-hozzárendelését bizonyítja, semmi mást. Kérdezze meg az operációs rendszert, hová menne egy nyilvános cím, amíg az alagút áll. Linuxon ip route get 1.1.1.1 az alagút interfészt kell megneveznie; macOS-en netstat -rn -f inet | head -5 az alapértelmezett bejegyzést mutatja; Windowsban Find-NetRoute -RemoteIPAddress 1.1.1.1 a kiválasztott interfészt és a következő ugrást írja ki.

Ezután olvassa el a split-tunnel jelzőt, mert ez dönti el, hogy a végpont által közzétett útvonalak-e az egyetlen célok, amelyeket a kliens az alagútba küld:

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

Ha a SplitTunnel true, egy nyilvános cél csak akkor használja az alagutat, ha a végpont közzétesz egy őt lefedő útvonalat, így a hiányzó 0.0.0.0/0 a helyi interfészen hagyja ezt a forgalmat. Ha false, a kliens elkapja a forgalmat, de a végpontnak még mindig irányítania és engedélyeznie kell; különben a csomagok belépnek az alagútba és ott megállnak. Módosítsa bármelyik beállítást, majd csatlakoztassa újra a klienst, mert az útvonalak és a DNS-kiszolgálók csatlakozáskor kerülnek átadásra, és egy futó kliens megtarthatja a régi készletét.

Olvassa külön a végpont útvonalát és az engedélyezési szabályt

Ez két objektum, és az egyik létrehozása nem hozza létre a másikat. Listázza a végpont útvonalait, és keressen olyan alapértelmezett útvonalat, amelynek célja kapcsolódó alhálózat:

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

Minden útvonalnak pontosan egy cél-alhálózata van, így három társításnak mindegyikhez megfelelő alapértelmezett útvonalra van szüksége. Az AWS dokumentálja ezt a lefedettségi követelményt, és a hiány gyakorlati tünete az a felhasználó, aki az egyik alhálózatból dolgozik, a másikból elakad, ami időszakos hibaként olvasható hiányzó útvonal helyett. A hivatalos Client VPN forgatókönyv-dokumentáció írja le azt a nyilvános alhálózati elrendezést, amelyhez ezek az útvonalak tartoznak.

Az engedélyezés a második objektum. Ha egyetlen szabály sem fedi a nyilvános célt, az alagút viszi a csomagot, és a szolgáltatás eldobja, így a privát erőforrások tovább működnek, az internet viszont nem:

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

A VPC CIDR-jére vonatkozó szabály semmit sem mond a 0.0.0.0/0 címről. A teljes alagút hiányzó darabjainak hozzáadása alhálózatonként egy útvonalat jelent plusz egy engedélyezési szabályt, amelyet később auditálhat:

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 a célt minden kliensnek megadja a végponton, ezért csak addig tartsa, amíg az alagútnak teljesnek kell lennie; a címtár-csoporthoz kötött szabály előnyösebb, ha vannak csoportjai, amelyekhez kötheti.

Kövesse a csomagot a kapcsolódó alhálózatból kifelé

A végpont útvonala dönti el, hogy az AWS átadja a csomagot annak az alhálózatnak. Nem dönti el az utána következő ugrást, amely az alhálózat saját VPC-útvonaltáblájában él:

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

Egy használható alapértelmezett útvonal internetkapura mutat nyilvános alhálózat esetén, vagy NAT-kapura privát esetén, és a blackhole állapot azt jelenti, hogy a cél törölve lett, és az útvonal most csendesen meghal. Ezek más táblák, mint a végpont útvonallistája, és az egyik javítása nem javítja a másikat.

Ezen az ugráson két szűrő ül. A cél hálózati társítására alkalmazott biztonsági csoportnak engedélyeznie kell a kimenő forgalmat a nyilvános cél felé, és minden alkalmazható hálózati ACL-nek engedélyeznie kell a kérést és a visszforgalmat az efemer portokon. A korlátozó társítási biztonsági csoport gyakori oka annak, hogy a privát hozzáférés működik, a nyilvános pedig nem.

A tünet alapján válassza az első réteget, ahelyett hogy mindhármat egyszerre módosítaná:

Válassza szét a DNS-hibát a halott útvonaltól

A névfeloldás másképp hibázik, mint a továbbítás, és a teljes alagút fontossá teszi a különbséget, mert a betolt feloldó most az alagúton keresztül érhető el. Ha a végpont VPC DNS-kiszolgálókat ad meg, azok címeinek is útvonal-lefedettségre és engedélyezésre van szükségük, mint bármely más célnak. Kérdezze meg közvetlenül a feloldót, hogy lássa, melyik hibája van: dig +short example.com @10.0.0.2, vagy nslookup example.com 10.0.0.2 Windowsban.

Ha egy numerikus URL válaszol, egy elnevezett pedig nem, hagyja abba az alapértelmezett útvonal szerkesztését, és a DNS-sel foglalkozzon. Az IP-címre küldött kérés semmit sem bizonyít egy elnevezett virtuális gazdagépről és annak tanúsítványáról, ezért tartson meg egy elnevezett tesztet a záró ellenőrzésben.

Az időzítés segít. Az a TCP-kapcsolat, amely néhány másodpercen belül nem kap választ, az irányításra vagy egy szűrőre mutat, míg a névkeresésben lógó kérés a feloldóra. Az alapértelmezett útvonal módosítása, miközben a feloldó elérhetetlen, általában egy hibát kettővé tesz.

Állítsa vissza tisztán, majd ellenőrizze a kimeneti útvonalat

Mindkét objektum hozzáadó jellegű volt, így a visszaállítás törlés, nem javítás:

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

Csatlakozzon újra, majd erősítse meg, melyik úton hagyja el a forgalom a hálózatot. Hasonlítsa össze a megfigyelt nyilvános címet a NAT-kapu rugalmas IP-címével, vagy azzal az internetkapuval, amelyet használni kívánt, és ellenőrizze, hogy egy privát erőforrás még válaszol-e ugyanabban a munkamenetben.

Fejezze be egy rövid listával, és kezelje az utolsó elemet a változás részeként, nem dokumentációként:

• Egy 0.0.0.0/0 végpontútvonal minden kapcsolódó alhálózathoz.
• Egy engedélyezési szabály, amely lefedi a 0.0.0.0/0 címet azoknak a klienseknek, amelyeket ki szeretne szolgálni.
• Egy nem blackhole állapotú VPC-alapértelmezett útvonal minden kapcsolódó alhálózaton.
• A társítási biztonsági csoport kimenete, plusz az ACL visszforgalma.
• A feloldó címei irányítva és engedélyezve, elnevezett kéréssel ellenőrizve.
• Egy rögzített visszaállítás az útvonalhoz és a szabályhoz.

Egy hatókör-megjegyzés: ez IPv4-útvonal. A kettős veremű kliens megtartja a már meglévő IPv6-kapcsolatát, így az IPv6-alapértelmezett útvonal külön döntés saját engedélyezéssel, nem ennek mellékhatása.