EC2 niyə AWS Client VPN laptopunuza çatmır
Client VPN IPv4 müştəri mənbələrini endpoint interfeysinə çevirir. Cavabın işləməsinin, EC2-dən yeni bağlantının isə işləməməsinin səbəbi budur.
AWS Client VPN ilə qoşulan laptop EC2 tətbiqinə problemsiz çatır. Sonra tərsini yoxlayırsınız: EC2-dən müştəriyə verilən ünvana, və bağlantı donur və ya rədd edilir. Bu asimmetriya nadir hallarda çatışmayan təhlükəsizlik qrupu qaydası olur. VPC alt şəbəkələri ilə əlaqələndirilmiş Client VPN endpointində AWS IPv4 müştəri mənbələrini endpointin şəbəkə interfeysinə çevirir, ona görə laptopunuzu təmsil edən heç bir daxil olan VPC ünvanı yoxdur.
Tutmanın göstərdiyi ilə başlayın
Müştəri qoşularkən EC2 hostunda paket tutması aparın və tətbiqin həqiqətən gördüyü mənbə ünvanını oxuyun. Əgər bu, müştəri hovuzundan bir ünvan deyil, VPC tərəfindəki endpoint interfeysidirsə, bir qaydanı belə dəyişməzdən əvvəl çevirmə təsdiqlənib.
Müştəri hovuzu qaytarma marşrutu olan alt şəbəkə deyil, ayrılan diapazondur. Bu fərq bu araşdırmaların çoxunun səhv getdiyi yerdir.
Asimmetriyanı izah edən çevirmə
Üç axın bir-biri ilə qarışdırılır və yalnız biri insanların sınaqdan keçirdiyi axındır.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN komponentlərinin təsviri IPv4 müştəri mənbələrinin endpoint interfeysinə çevrildiyini açıq şəkildə deyir; bu da orta sətrin niyə uyğunlaşacaq heç nə tapmadığını görmək üçün kifayətdir.
Yeni bağlantı marşrut, ünvanın həlli addımı və icazə qərarı tələb edir. Başqasının sessiyasından qalan çevirmə vəziyyəti bu üçünün heç birini vermir.
Cavab niyə yeni bağlantı deyil
TCP cavabı mövcud qeyd ilə uyğunlaşdırılır, ona görə qaytarma yolu heç bir daxil olan qayda olmadan işləyir. EC2 hostundan gələn təzə SYN isə uyğunlaşacaq qeyd tapmır və VPC-nin necə çatacağını bilmədiyi ünvana adi çıxan cəhdə çevrilir.
Buna görə də bunu yalnız bir istiqamətdə gedən trafik kimi təsvir etmək yanıltıcıdır. Bu sessiyalarda qaytarma trafiki davamlı axır. Yolun olmadığı hissə başlanğıcdır.
İşləməli olan sessiyanı hələ də nə pozur
Təhlükəsizlik qrupları, şəbəkə ACL-ləri və laptopun öz firewall-u uğur qazanmalı olan bağlantılar üçün hamısı vacibdir. Uğursuz ping ən az məlumat verir, çünki ICMP siyasəti çox vaxt sizi maraqlandıran TCP siyasətindən ayrıdır.
Bu qaydaları çevrilmiş mənbəyə görə yazın, müştəri ünvanına görə deyil. Şəbəkədə heç vaxt görünməyən ünvana bağlanmış qaydalar bu dizaynda ən çox rast gəlinən özünə vurduğun zərərdir.
VPC həqiqətən söhbətə başlamalı olduqda
Əgər xidmət iş stansiyasına bildiriş göndərməlidirsə, istiqaməti tərsinə çevirin və müştərinin xidmətin cavab verdiyi davamlı çıxan kanal saxlamasına icazə verin. Əgər bütöv uzaq şəbəkə VPC-dən əlçatan olmalıdırsa, Client VPN-in bunu artıq etdiyini fərz etmək əvəzinə prefikslərini və giriş siyasətini yayan arxitektura seçin. Müştəridən müştəriyə giriş öz marşrut və icazə obyektləri olan üçüncü, daha dar haldır. Bunların heç biri mövcud endpointdə sadəcə işarələnən seçim deyil.
IPv4 izahının əhatəsini də dürüst saxlayın. Hazırkı AWS sənədləri IPv6-nı, orada bu çevirmənin tətbiq olunmadığını, və fərqli yönləndirən digər qoşulma modellərini ayırır.
Üç etiketli addımda sınaqdan keçirin: müştəri icazəli sessiya açır, VPC xidməti həmin sessiyaya cavab verir, və VPC hostu müştəriyə doğru yeni sessiya açır. İlk ikisinin uğurlu, üçüncünün uğursuz olması bu dizaynın gözlənilən formasıdır, firewall qaydaları ilə qovulacaq qüsur deyil.