AWS Client VPN qoşulub, amma internetə çıxış yoxdur: marşrut yoxlamaları

AWS Client VPN qoşulub, internetə çıxış yoxdur? Müştəri marşrutlarını, son nöqtə avtorizasiyasını, alt şəbəkə çıxışını və DNS-i bu sıra ilə yoxlayın.

Siz AWS Client VPN son nöqtəsinə qoşulmusunuz, özəl alt şəbəkə cavab verir, amma hər açıq səhifə yenə vaxt aşımına düşür. Bu birləşmə problemi idarə olunan tərəfdəki üç obyektdən birinə daraldır: müştərinin quraşdırdığı marşrut, son nöqtənin marşrutu və onun avtorizasiya qaydası, ya da əlaqəli alt şəbəkənin növbəti sıçrayışı. Onları bu sıra ilə yoxlayıram, çünki hər nasazlıq müştəri tərəfindən fərqli görünür. Bu təlimat VPC ilə əlaqəli idarə olunan son nöqtəni əhatə edir; EC2 instansiyasındakı OpenVPN serverini və nə Cloud WAN, nə də Transit Gateway qoşmasını əhatə etmir.

Müştərinin həqiqətən nəyi marşrutlaşdırdığından başlayın

Qoşulma vəziyyəti TLS sessiyasını və müştəri CIDR təyinatını sübut edir, başqa heç nəyi. Tunnel açıqkən açıq ünvana hara gediləcəyini əməliyyat sistemindən soruşun. Linux-da ip route get 1.1.1.1 tunnel interfeysini göstərməlidir; macOS-da netstat -rn -f inet | head -5 standart qeydi göstərir; Windows-da Find-NetRoute -RemoteIPAddress 1.1.1.1 seçilmiş interfeysi və növbəti sıçrayışı çap edir.

Sonra split-tunnel bayrağını oxuyun, çünki o, son nöqtənin dərc etdiyi marşrutların müştərinin tunelə göndərdiyi yeganə təyinat olub-olmadığını həll edir:

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

Əgər SplitTunnel doğrudursa, açıq təyinat tuneldən yalnız son nöqtə onu əhatə edən marşrut dərc etdikdə istifadə edir, ona görə də çatışmayan 0.0.0.0/0 həmin trafiki yerli interfeysdə saxlayır. Yalandırsa, müştəri trafiki tutur, amma son nöqtə onu yenə marşrutlaşdırmalı və avtorizasiya etməlidir; əks halda paketlər tunelə girib orada dayanır. Hər iki parametri dəyişdikdən sonra müştərini yenidən qoşun, çünki marşrutlar və DNS serverləri qoşulma anında verilir və işləyən müştəri köhnə dəstini saxlaya bilər.

Son nöqtə marşrutunu və avtorizasiya qaydasını ayrı-ayrılıqda oxuyun

Bunlar iki obyektdir və birini yaratmaq digərini yaratmır. Son nöqtə marşrutlarını sadalayın və hədəfi əlaqəli alt şəbəkə olan standart marşrut axtarın:

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

Hər marşrutun dəqiq bir hədəf alt şəbəkəsi var, ona görə də üç əlaqə hər biri üçün uyğun standart marşrut tələb edir. AWS bu əhatə tələbini sənədləşdirir və boşluğun praktik simptomu bir alt şəbəkədən işləyib digərindən ilişib qalan istifadəçidir; bu, çatışmayan marşrut yerinə fasilələrlə təkrarlanan nasazlıq kimi görünür. Rəsmi Client VPN ssenari sənədləri bu marşrutların aid olduğu açıq alt şəbəkə quruluşunu təsvir edir.

Avtorizasiya ikinci obyektdir. Açıq təyinatı heç bir qayda əhatə etmədikdə tunel paketi daşıyır və xidmət onu atır, buna görə özəl resurslar işləməyə davam edir, internet isə etmir:

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

VPC CIDR üçün qayda 0.0.0.0/0 barədə heç nə demir. Tam tunel üçün çatışmayan hissələri əlavə etmək hər əlaqəli alt şəbəkə üçün bir marşrut və sonradan yoxlaya biləcəyiniz avtorizasiya qaydası deməkdir:

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 təyinatı son nöqtənin hər müştərisinə verir, ona görə də onu yalnız tunel tam olmalı olduqda saxlayın; kataloq qrupuna bağlanmış qayda, bağlamaq üçün qruplarınız olduqda daha üstündür.

Paketi əlaqəli alt şəbəkədən kənara izləyin

Son nöqtə marşrutu AWS-in paketi həmin alt şəbəkəyə verdiyini həll edir. Ondan sonrakı sıçrayışı həll etmir; o, alt şəbəkənin öz VPC marşrut cədvəlindədir:

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

İstifadə oluna bilən standart marşrut açıq alt şəbəkə üçün internet şlüzünə, özəl olan üçün NAT şlüzünə işarə edir və blackhole vəziyyəti hədəfin silindiyini və yolun indi səssizcə öldüyünü bildirir. Bunlar son nöqtənin marşrut siyahısından fərqli cədvəllərdir və birini təmir etmək digərini təmir etmir.

Bu sıçrayışda iki filtr var. Hədəf şəbəkə əlaqəsinə tətbiq olunan təhlükəsizlik qrupu açıq təyinat istiqamətində çıxış trafikinə icazə verməlidir və tətbiq olunan istənilən şəbəkə ACL sorğuya və efemer portlarda qayıdış trafikinə icazə verməlidir. Məhdudlaşdırıcı əlaqə təhlükəsizlik qrupu özəl girişin işləyib açıq girişin işləməməsinin geniş yayılmış səbəbidir.

Simptoma görə ilk təbəqəni seçin, hər üçünü eyni anda dəyişməyin:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

DNS nasazlığını ölü marşrutdan ayırın

Ad həlli yönləndirmədən fərqli şəkildə sıradan çıxır və tam tunel bu fərqi vacib edir, çünki göndərilən resolver artıq tuneldən keçir. Son nöqtə VPC DNS serverlərini göstərirsə, onların ünvanları hər hansı digər təyinat kimi marşrut əhatəsi və avtorizasiya tələb edir. Hansı nasazlığın olduğunu görmək üçün resolverə birbaşa sorğu göndərin: dig +short example.com @10.0.0.2, ya da nslookup example.com 10.0.0.2 Windows-da.

Rəqəmsal URL cavab verib adlı URL vermədikdə standart marşrutu redaktə etməyi dayandırın və DNS üzərində işləyin. IP ünvana sorğu adlı virtual host və onun sertifikatı barədə heç nə sübut etmir, ona görə də yekun yoxlamada bir adlı test saxlayın.

Vaxtlama kömək edir. Bir neçə saniyə içində cavab almayan TCP bağlantısı marşrutlaşdırma və ya filtrə işarə edir, ad axtarışı içində ilişib qalan sorğu isə resolverə. Resolver əlçatmazkən standart marşrutu dəyişmək adətən bir nasazlığı ikiyə çevirir.

Təmiz geri qaytarın, sonra çıxış yolunu yoxlayın

Hər iki obyekt əlavə xarakterli idi, ona görə geri qaytarma təmir deyil, silməkdir:

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

Yenidən qoşulun və trafikin hansı yolla çıxdığını təsdiqləyin. Müşahidə olunan açıq ünvanı NAT şlüzünün elastik IP ünvanı ilə və ya istifadə etmək istədiyiniz internet şlüzü ilə müqayisə edin və özəl resursun həmin sessiyada hələ cavab verdiyini yoxlayın.

Qısa siyahı ilə bitirin və son bəndi sənədləşmə deyil, dəyişikliyin hissəsi kimi qəbul edin:

  • Hər əlaqəli alt şəbəkə üçün bir 0.0.0.0/0 son nöqtə marşrutu.
  • Xidmət etmək istədiyiniz müştərilər üçün 0.0.0.0/0 əhatə edən avtorizasiya qaydası.
  • Hər əlaqəli alt şəbəkədə blackhole olmayan VPC standart marşrutu.
  • Əlaqə təhlükəsizlik qrupunun çıxışı, üstəgəl ACL qayıdış trafiki.
  • Resolver ünvanları marşrutlaşdırılıb və avtorizasiya olunub, adlı sorğu ilə yoxlanılıb.
  • Marşrut və qayda üçün qeydə alınmış geri qaytarma.

Bir əhatə qeydi: bu IPv4 yoludur. İki yığımlı müştəri artıq malik olduğu IPv6 bağlantısını saxlayır, ona görə IPv6 standart marşrutu bunun yan təsiri deyil, öz avtorizasiyası olan ayrı qərardır.

Əlaqəli məqalələr