Bir AWS Client VPN sessiyası arxasında LAN: nə ötürülür

Noutbuk AWS Client VPN son nöqtəsinə qoşulur, xüsusi alt şəbəkəyə çatır və hər şey sağlam görünür. Eyni LAN-dakı masaüstü kompüter heç bir yerə çatmır, baxmayaraq ki, Linux hostunda da körpü interfeysi var və hər iki maşın eyni naqildədir. Tuneldə heç nə səhv konfiqurasiya olunmayıb; çatışmayan hissə marşrutlaşdırmadır və körpü yanlış istiqamətdir.

Client VPN sessiyasını LAN-a genişləndirmək şlüz roludur. Bu, idarə olunan xidmətə uzadılmış Ethernet seqmenti deyil.

Host işləyir, LAN isə yox

Linux qutusundakı tunel interfeysinin Client VPN müştəri CIDR-i daxilində ünvanı var və son nöqtə VPC diapazonları üçün marşrutlar göndərib. Həmin qutuda edilən sorğu lokal yaradılan trafikdir: marşrut seçir, tuneldən çıxır və cavab alır. Bu yol heç vaxt ötürmə koduna, LAN interfeysinə və ya tranziti idarə edən hər hansı firewall qaydasına toxunmur.

Başqa bir LAN cihazından gələn trafik fərqli axındır. O, LAN interfeysinə gəlir, tunelə yönələn marşruta ehtiyac duyur, ötürmənin aktiv olmasını, ona icazə verən firewall tələb edir və cavabın eyni hostdan geri qayıtmasını tələb edir. Dörd tələb, və işləyən noutbuk testi onların heç birini sübut etmir. Masaüstündən nasazlıq qəribə görünür: tunel açıqdır, etimadnamələr etibarlıdır və təyinat sadəcə heç vaxt cavab vermir. Qüsur xidmətdə deyil, şlüzün ötürmə yolundadır.

Hər müştəri şlüz ola bilməz

AWS bildirir ki, onun Client VPN masaüstü tətbiqi IP ötürməsini dəstəkləmir, digər müştərilər isə dəstəkləyə bilər. Bu məhdudiyyət arxitekturanı hər hansı əmr yazılmazdan əvvəl müəyyən edir. Əgər mövcud olan yeganə müştəri rəsmi masaüstü tətbiqidirsə, LAN üçün ötürmə edən Linux şlüzü tamamlaya biləcəyiniz konfiqurasiya deyil və heç bir masquerading bunu dəyişməz.

Əvəzedici müştəri həm də son nöqtənin autentifikasiya üsuluna və tətbiq etmək istədiyiniz siyasətə uyğun olmalıdır. Sertifikat əsaslı, kataloq əsaslı və SAML dəstəkli son nöqtələr eyni müştəri konfiqurasiyalarını qəbul etmir və autentifikasiyadan keçən, lakin göndərilən marşrutları nəzərə almayan üçüncü tərəf müştərisi təkmilləşdirmə deyil.

Müştəri seçiminə dizayn baxışının bir hissəsi kimi baxın. O, LAN ötürmə modelinin ümumiyyətlə mövcud olub-olmadığını və son nöqtənin şlüz arxasındakı hər cihaz üçün hansı identikliyi gördüyünü müəyyən edir. Müştərini və sınaqdan keçirildiyi son nöqtə konfiqurasiyasını qeyd edin. Altı ay sonra müştərinin dəyişdirilməsi dizaynın güman etdiyi imkanı səssizcə silə bilər.

LAN-ı tunelə yönəldin və tərcümə edin

Dəstəklənən müştəri yerində olduqda, qalanı adi şlüz işidir. LAN cihazları VPC diapazonu üçün Linux hostuna yönələn marşruta ehtiyac duyur, host isə ötürmənin aktiv olmasına ehtiyac duyur. Əgər VPC trafiki ixtiyari LAN ünvanı kimi deyil, qoşulmuş müştəri kimi görməsini istəyirsinizsə, çıxışda mənbəni tərcümə edin.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Qaydayı yuxarıdakı kimi tunel interfeysi və VPC diapazonu ilə məhdudlaşdırın, hostun ötürdüyü hər şeyi masquerade etməyin. Dar qayda haqqında düşünmək daha asandır və ilkin mənbə ünvanını saxlamalı olan trafiki səssizcə dəyişmir.

Mümkünsə LAN marşrutunun avtomatik gəlməsini təmin edin: DHCP seçimi, marşrutlaşdırıcı elanı və ya LAN-ı idarə edən tərəfindən göndərilən statik marşrut. Yalnız bir test maşınında mövcud olan marşrut, başqası sınadığı anda dizaynı pozulmuş kimi göstərəcək.

Cavabın da yola ehtiyacı var

Sorğu VPC-yə çatdıqdan sonra cavab eyni tərcümə vəziyyətlərindən geri qayıtmalı və şlüzdə LAN marşrutunu tapmalıdır. Bu hissə adətən masquerade qaydası mövcud olduqda işləyir, çünki xəritələmə onu yerinə yetirən hostda yaşayır. Cavabı başqa yerə göndərən marşrut VPC tərəfində olduqda pozulur; buna görə də həm müştəri CIDR marşrutu, həm də son nöqtədəki alt şəbəkə assosiasiyası vacibdir.

Yalnız ping-ə deyil, sayğaclara baxın. Sıfır paketli masquerade qaydası sizə sorğunun heç vaxt tunel interfeysinə çatmadığını bildirir, bu da LAN marşrutuna və ya müştərinin öz marşrut cədvəlinə işarə edir. Paketləri olan, lakin cavabsız qayda VPC tərəfinə, avtorizasiya qaydalarına və ya tərcümə edilmiş mənbəni qəbul etməyən təhlükəsizlik qrupuna işarə edir. Hər şeyi dəyişməzdən əvvəl hər iki istiqaməti oxuyun, çünki yalnız bir tərəfdə artan say birtərəfli yoldur, yavaş yol deyil.

Unutmayın ki, son nöqtə idarə olunan xidmətdir. Redaktə ediləcək server konfiqurasiya faylı və əlavə ediləcək client-config direktivi yoxdur, buna görə fərdi müştəri alt şəbəkə marşrutları ilə özünü idarə edən OpenVPN serveri üçün yazılmış təlimatlar keçərli deyil. AWS-də rıçaqlar alt şəbəkə assosiasiyası, avtorizasiya qaydaları və VPC marşrut cədvəlləridir.

Paylaşılan identiklik siyasətin cavab verməli olduğu hissədir

Şlüz arxasındakı hər cihaz şlüzün VPN sessiyasından istifadə edir. Son nöqtənin avtorizasiya qaydaları istifadəçiyə və ya qrupa giriş verir və xidmətin nöqteyi-nəzərindən həmin sessiyada tam olaraq bir istifadəçi var. Lokal ötürmə bu identikliyi cihaz üzrə autentifikasiyaya çoxaltmır və cihaz posturası yoxlamalarını küncdəki printerə qədər uzatmır.

Bu məqbul ola bilər, ya da dizaynın rədd edilməsinin səbəbi ola bilər. Bu, VPC resurslarının kimin zəng etdiyi barədə nə güman etdiyindən asılıdır. Avtorizasiya modelinə uyğun paylaşılan identiklik yaxşıdır; tək autentifikasiya olunmuş sessiyanı səssizcə LAN miqyaslı girişə çevirən biri isə yazılmağı gözləyən bir tapıntıdır.

Tələb həqiqətən bütöv bir saytı VPC-yə qoşmaqdırsa, uzaq giriş müştərisini genişləndirməzdən əvvəl dəstəklənən sayt-sayt dizaynını müqayisə edin. Semantika fərqlidir və VPC LAN-a bağlantılar başlatmalı olduqda NAT-lanmış müştəri sessiyası sayt bağlantısı üçün zəif əvəzedicidir.

Müştərini, marşrutu, tərcüməni və identiklik hekayəsini bu ardıcıllıqla qərarlaşdırın. Hər biri növbətini məhdudlaşdırır və ardıcıllıq hostun niyə işlədiyini, LAN-ın isə işləmədiyini izah edir.