AWS Client VPN bağlı ama internet yok: rotaları denetleme

AWS Client VPN uç noktasına bağlısınız, özel alt ağ yanıt veriyor, ama her genel sayfa yine de zaman aşımına uğruyor. Bu birleşim sorunu yönetilen taraftaki üç nesneden birine daraltıyor: istemcinin kurduğu rota, uç noktanın rotası ve yetkilendirme kuralı, ya da ilişkili alt ağın sonraki atlaması. Onları bu sırayla denetliyorum çünkü her arıza istemci tarafından farklı görünüyor. Bu kılavuz VPC ile ilişkili yönetilen uç noktayı kapsar; EC2 örneğindeki bir OpenVPN sunucusunu ya da Cloud WAN veya Transit Gateway bağlantısını kapsamaz.

İstemcinin gerçekte neyi yönlendirdiğiyle başlayın

Bağlı durumu yalnızca TLS oturumunu ve istemciye CIDR atamasını kanıtlar, daha fazlasını değil. Tünel açıkken genel bir adresin nereye gideceğini işletim sistemine sorun. Linux'ta ip route get 1.1.1.1 tünel arayüzünü adlandırmalıdır; macOS'ta netstat -rn -f inet | head -5 varsayılan girdiyi gösterir; Windows'ta Find-NetRoute -RemoteIPAddress 1.1.1.1 seçilen arayüzü ve sonraki atlamayı yazdırır.

Ardından split-tunnel bayrağını okuyun, çünkü uç noktanın yayımladığı rotaların istemcinin tünele gönderdiği tek hedef olup olmadığına bu karar verir:

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

Şu durumda SplitTunnel true ise, genel bir hedef tüneli yalnızca uç nokta onu kapsayan bir rota yayımladığında kullanır, bu yüzden eksik 0.0.0.0/0 o trafiği yerel arayüzde bırakır. false ise istemci trafiği yakalar, ama uç nokta onu yine de yönlendirmeli ve yetkilendirmelidir; aksi halde paketler tünele girer ve orada durur. İki ayardan birini değiştirdikten sonra istemciyi yeniden bağlayın, çünkü rotalar ve DNS sunucuları bağlantı anında teslim edilir ve çalışan bir istemci eski kümeyi koruyabilir.

Uç nokta rotasını ve yetkilendirme kuralını ayrı ayrı okuyun

Bunlar iki nesnedir ve birini oluşturmak diğerini oluşturmaz. Uç nokta rotalarını listeleyin ve hedefi ilişkili bir alt ağ olan varsayılan bir rota arayın:

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

Her rotanın tam olarak bir hedef alt ağı vardır, bu yüzden üç ilişkilendirme her biri için uygun bir varsayılan rota gerektirir. AWS bu kapsama gereksinimini belgeler ve boşluğun pratik belirtisi, bir alt ağdan çalışıp diğerinden takılan kullanıcıdır; bu, eksik rota yerine aralıklı bir arıza olarak okunur. Resmi Client VPN senaryo belgeleri bu rotaların ait olduğu genel alt ağ düzenini açıklar.

Yetkilendirme ikinci nesnedir. Hiçbir kural genel hedefi kapsamadığında tünel paketi taşır ve hizmet onu atar, bu yüzden özel kaynaklar çalışmaya devam ederken internet çalışmaz:

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

VPC CIDR'ı için bir kural 0.0.0.0/0 hakkında hiçbir şey söylemez. Tam bir tünel için eksik parçaları eklemek, ilişkili her alt ağ için bir rota ve sonradan denetleyebileceğiniz bir yetkilendirme kuralı demektir:

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 hedefi uç noktanın her istemcisine verir, bu yüzden yalnızca tünelin tam olması gerektiği sürece tutun; bağlamak için gruplarınız varsa dizin grubuna bağlı bir kural daha iyidir.

Paketi ilişkili alt ağdan dışarı izleyin

Uç nokta rotası AWS'nin paketi o alt ağa verdiğine karar verir. Ondan sonraki sonraki atlamaya karar vermez; o, alt ağın kendi VPC rota tablosunda yaşar:

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

Kullanılabilir bir varsayılan rota, genel alt ağ için bir internet ağ geçidine ya da özel alt ağ için bir NAT ağ geçidine işaret eder, ve blackhole durumu hedefin silindiğini ve yolun artık sessizce öldüğünü gösterir. Bunlar uç noktanın rota listesinden farklı tablolardır ve birini onarmak diğerini onarmaz.

Bu atlamada iki filtre var. Hedef ağ ilişkilendirmesine uygulanan güvenlik grubu genel hedefe giden çıkış trafiğine izin vermelidir ve geçerli herhangi bir ağ ACL'si isteğe ve kısa ömürlü bağlantı noktalarındaki dönüş trafiğine izin vermelidir. Kısıtlayıcı bir ilişkilendirme güvenlik grubu, özel erişimin çalışıp genel erişimin çalışmamasının yaygın bir nedenidir.

Üçünü birden değiştirmek yerine belirtiye göre ilk katmanı seçin:

DNS arızasını ölü rotadan ayırın

Ad çözümlemesi iletmeden farklı biçimde başarısız olur ve tam tünel bu farkı önemli kılar, çünkü zorlanan çözümleyiciye artık tünel üzerinden ulaşılır. Uç nokta VPC DNS sunucuları belirtiyorsa, adreslerinin diğer her hedef gibi rota kapsamına ve yetkilendirmeye ihtiyacı vardır. Hangi arızanın olduğunu görmek için çözümleyiciye doğrudan sorun: dig +short example.com @10.0.0.2, ya da nslookup example.com 10.0.0.2 Windows'ta.

Sayısal bir URL yanıt verip adlı olan vermediğinde, varsayılan rotayı düzenlemeyi bırakın ve DNS ile uğraşın. Bir IP adresine istek, adlı bir sanal ana bilgisayar ve sertifikası hakkında hiçbir şey kanıtlamaz, bu yüzden son denetimde adlı bir test bırakın.

Zamanlama yardımcı olur. Birkaç saniye içinde yanıt almayan TCP bağlantısı yönlendirmeye ya da bir filtreye işaret eder, ad araması içinde asılı kalan istek ise çözümleyiciye işaret eder. Çözümleyici erişilemezken varsayılan rotayı değiştirmek genellikle bir arızayı ikiye çıkarır.

Temiz biçimde geri alın, ardından çıkış yolunu doğrulayın

İki nesne de eklemeliydi, bu yüzden geri alma onarım değil silmedir:

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

Yeniden bağlanın ve trafiğin hangi yoldan çıktığını doğrulayın. Gözlenen genel adresi NAT ağ geçidinin esnek IP adresiyle ya da kullanmayı düşündüğünüz internet ağ geçidiyle karşılaştırın ve özel bir kaynağın aynı oturumda hâlâ yanıt verdiğini denetleyin.

Kısa bir listeyle bitirin ve son maddeyi belge değil değişikliğin parçası olarak ele alın:

• İlişkili her alt ağ için bir 0.0.0.0/0 uç nokta rotası.
• Hizmet vermek istediğiniz istemciler için 0.0.0.0/0 adresini kapsayan bir yetkilendirme kuralı.
• İlişkili her alt ağda blackhole durumunda olmayan bir VPC varsayılan rotası.
• İlişkilendirme güvenlik grubunun çıkışı ve ACL dönüş trafiği.
• Çözümleyici adresleri yönlendirildi ve yetkilendirildi, adlı istekle doğrulandı.
• Rota ve kural için kaydedilmiş geri alma.

Bir kapsam notu: bu bir IPv4 yoludur. Çift yığınlı istemci zaten sahip olduğu IPv6 bağlantısını korur, bu yüzden IPv6 varsayılan rotası bunun yan etkisi değil, kendi yetkilendirmesi olan ayrı bir karardır.