AWS Client VPN-də fasilələrlə giriş: hər əlaqəli subneti yoxlayın

Bir istifadəçi qoşulur, daxili tətbiqi açır və cavab alır; eyni endpoint-də olan həmkarı isə eyni Wi-Fi-da eyni noutbukdan timeout alır. Bu mənzərə birdən çox əlaqəli subneti olan client VPN endpoint-in əlamətidir və burada yollar ekvivalent deyil. Mən bunu konsoldan bayıra doğru izləyirəm, çünki iki tab qalan araşdırmanın dəyərli olub-olmadığını müəyyən edir. Client konfiqurasiyasında bunu izah edən heç nə yoxdur.

Endpoint-dən başlayın və əlaqələri sadalayın

VPC konsolunda Client VPN endpoints bölməsini açın, endpoint-i seçin və Associations tabına baxın. Hər əlaqə bir Availability Zone-dakı subnetdir və client bağlantı qurularkən xidmətin seçdiyi subnetə düşür. Subnet ID-lərini və hər birinin faktiki istifadə etdiyi marşrut cədvəlini qeyd edin, çünki bu iki siyahı etmək üzrə olduğunuz müqayisədir.

Əgər endpoint yalnız bir əlaqə göstərirsə, bu nəzəriyyə səhvdir və client daha yaxşı şübhəlidir.

Endpoint marşrut cədvəlini hər əlaqə ilə müqayisə edin

Həmin endpoint-də Route table tabını açın. Oradakı hər təyinat CIDR-inin bir hədəfi var və client VPN-də hədəf gateway deyil, əlaqədir. AWS hər əlaqəli subnet üçün təyinat qeydi tələb edir, ona görə yalnız birini hədəfləyən marşrut girişi sessiyanın hara düşdüyündən asılı edir. Əslində vacib olan təyinatı yoxlayın, sonra onun avtorizasiya qaydasını yoxlayın, çünki marşrut yolu verir, qayda isə kimin istifadə edə biləcəyini müəyyən edir.

Hər iki qatı cədvələ saldıqdan sonra nasazlığı gözdən qaçırmaq çətindir.

İkinci sətir əksər ticket-lərdə bütün xətanın özüdür. Endpoint marşrutu mövcuddur, ona görə heç kim daha irəli baxmır və paket bir hop sonra VPC-nin içində ölür.

Hər subneti öz effektiv marşrut cədvəlinə qədər izləyin

Açıq marşrut cədvəli əlaqəsi olmayan subnet VPC-nin əsas cədvəlini miras alır. Adı düzgün görünən cədvəli deyil, faktiki qüvvədə olan cədvəli oxuyun və sətirdəki etiketi deyil, təyinatı və hədəfi müqayisə edin.

AWS-in fasilələrlə giriş bələdçisi bunu əlaqələr üzrə marşrut əhatəsi kimi təqdim edir və bu, düzgün modeldir. Endpoint paketi subnetə çatdırır və həmin subnetin cədvəli hələ də tətbiq şəbəkəsinin harada olduğunu bilməlidir.

Çatışmayan sətri ona sahib olan cədvəldə düzəldin. İşləyən subnetdən bütöv marşrut cədvəlini kopyalamaq internet, cihaz və izolyasiya seçimlərini də kopyalayır ki, onlar heç vaxt bu subnet üçün nəzərdə tutulmayıb və bu mübadilə adətən başladığınız kəsintidən daha pisdir.

Avtorizasiya qaydalarını, sonra geri yolu yoxlayın

Avtorizasiya qaydaları hər təyinat və hər qrup üçündür və marşrutlardan ayrı qiymətləndirilir. Hər yerdə marşrutu olan, lakin istifadəçinin qrupu üçün qaydası olmayan təyinat sağlam görünən marşrut cədvəli ilə qara dəlik kimi davranır.

Geri yol da eyni diqqətə layiqdir. Peering bağlantısı tətbiq VPC-də client CIDR-inə geri baxan marşrut, trafiki hər iki tərəfdə icazə verən təhlükəsizlik qrupu qaydaları və onu atmayan şəbəkə ACL-ləri tələb edir. Birtərəfli əlçatanlıq, yəni ping işləyir və TCP handshake işləmir, adətən VPN-ə deyil, ACL və ya təhlükəsizlik qrupuna işarə edir.

Endpoint-in öz təhlükəsizlik qrupları əlaqənin elastik şəbəkə interfeyslərində yerləşir, ona görə tətbiq portuna client CIDR-indən icazə verən qayda yalnız instansiyaya deyil, əlaqəyə də bağlanmalıdır.

Bir şanslı sorğu ilə deyil, yenidən qoşulmaqla yoxlayın

Split tunnel ilə endpoint marşrutları bağlantı qurularkən ötürülür, ona görə dəyişmiş marşrut dəsti bağlı qalan client-ə heç vaxt çatmır. Dəstəklənən client vasitəsilə əlaqəni kəsin və yenidən qoşulun, sonra yeni marşrutların maşında mövcud olduğunu təsdiqləyin.

Nəhayət, bağlantı jurnalını client-in aldığı ünvanla uzlaşdırın və testi birdən çox əlaqəyə düşəcək qədər təkrarlayın. Düzəlişdən sonra tək uğurlu sorğu bir yolun işlədiyini sübut edir, ticket isə digər yol haqqında idi.