İki VPN atlaması ard-arda: trafikinizi əslində kim görür?

Hər müştəri profili bir server adlandırır, yəni istifadəçi yerindən bir tunel və qorunmanın bitdiyi bir yer var. O birinci şlüzdan sonra nə baş verdiyi müştərinin heç vaxt görmədiyi dizayn qərarıdır və iki geniş yayılmış dizayn yoxlama altında çox fərqli davranır. Ardıcıl zəncirdə birinci şlüz şifrəni açır və yenidən şifrələyir. İç-içə zəncirdə isə xarici qatı çıxarır və aça bilmədiyi daxili tuneli ötürür. Atlamaların sayı hər ikisində eynidir, buna görə fərqi saymaq yox, çəkmək lazımdır.

Müştəridən başlayın və hər iki son nöqtəni adlandırın

İstifadəçinin başladığı yerdən, yəni bağlantı profilindən başlayın. Orada bir uzaq ünvan, bir autentifikasiya üsulu və dizayn dəstəklədikdə marşrut siyahısı var. Müştəridən A şlüzünə gedən həmin xarici tuneli adlandırın və ona nümunə ünvanlar verin: müştərinin tunel ünvanı 10.77.0.2, A-nın ünvanı 10.77.0.1 və A-nın açıq son nöqtəsi 198.51.100.10, TEST-NET-2 sənədləşmə diapazonundan götürülüb ki, nümunədəki heç nə real hostla toqquşmasın.

O profildə B şlüzündən heç nə yazılmayıb və bu qüsur deyil. İkinci atlama A-ya aiddir və müştərinin yeganə öhdəliyi trafiki A-ya çatdırmaq və geri gələni qəbul etməkdir. A tuneli sonlandırır, ötürür, yoxsa yenisini açır — bu sualın cavabını bu gəzintinin qalan hissəsi verir və A-nın nəyi oxuya biləcəyini də elə bu müəyyən edir.

Ardıcıl: A şifrəni açır, sonra yenidən şifrələyir

Ardıcıl dizaynda A trafiki iki dəfə sonlandırır. Müştəridən qorunmanı çıxarır, tətbiqin IP paketini alır və sonra həmin paketi A-nın B-yə doğru başlatdığı ikinci tuneldən göndərir. Bu iki əməliyyat arasında paket A-nın yönləndirmə yolunda özəl ünvana ünvanlanmış adi IP paketi kimi dayanır.

Bu, açıq deməyə dəyər iki nəticə verir. A daxili paketə marşrutlar, filtr qaydaları və mənbə-təyinat jurnallaşdırması şəklində siyasət tətbiq edə bilər və A iki dəst etimad məlumatı saxlamalıdır: biri müştəri üçün server kimi, biri B-nin müştərisi kimi. Qorunma hər an mövcuddur, amma qorunan obyekt A-da kimliyini dəyişir.

Bu, A-nın tətbiq mətnini açıq oxuduğu anlamına gəlmir. Müştəri və xidmət TLS işlədib bir-birinin sertifikatını yoxladıqda, A oxunaqlı sorğu yox, TLS qeyd axını görür. Qorunmanın harada bitdiyini təsdiqləmək tunel sxeminə yox, xidmətin sertifikat zəncirinə baxmağı tələb edir.

İç-içə: A yalnız xarici qatı çıxarır

İç-içə dizaynda müştəri əvvəlcə B-yə daxili tunel qurur, sonra həmin tuneli xarici tunelin içində A-ya daşıyır. A xarici başlığı soyur, daxili tunel tapır və açarlarını saxlamadan onu ötürür, buna görə daxili qorunma yenə də B-də sonlanır.

Beləliklə müştərinin yuxarı kanalı iki qat, A ilə B arasındakı yol isə bir qat daşıyır. A daxili tunelin xarici ünvanlarını görür; bu, trafikin mövcud olduğunu və təxminən hara getdiyini bilməyə çatır, yükü oxumağa isə çatmır. Ardıcıl haldan bütün fərq budur və heç bir atlama sayğacı bunu göstərmir. A-nın hələ edə bildiyi şey oxuya bilmədiyini ötürməkdən imtina etməkdir və bu, həmin şlüzün operatoru üçün həmişə açıqdır.

İç-içəlik bu xassə üçün haqq alır. Hər qat başlıq yükü əlavə edir, ona görə MTU və MSS planlaması səliqədən çox məcburi olur və bir qatla işləyən yol iki qatla böyük paketləri səssizcə itirə bilər. Hər qat öz yenidən qoşulma və canlı saxlama davranışına ehtiyac duyur, bir qatdakı nasazlıq isə digərindən qismən kəsinti kimi görünür.

Yalnız tunelləri deyil, müşahidəçiləri çəkin

Tunellər rəsmin asan hissəsidir. Dizaynın mövzusu müşahidəçilərdir, ona görə hər baxış nöqtəsi üçün bir sətir yazın və hər birinin həqiqətən nə oxuya bildiyini doldurun.

İki sətir daim qarışdırılır: A-nın operatoru və müştərinin tunelinin provayderi. Onlar bir qurum ola bilər və ayrı şlüz adları onları müstəqil etmir. Müstəqil sahiblik ayrı inzibati nəzarət, ayrı etimad məlumatları və ayrı jurnallaşdırma tələb edir.

Metaməlumat hər iki dizaynda sağ qalır. Vaxt, paket ölçüləri və bağlantı sayları hər atlamada müşahidə oluna bilən qalır, yəni iki atlama siqnalı silmir, korrelyasiyanın qiymətini qaldırır. Görünməzlik vəd edən dizayn hər kəs ona güvənməzdən əvvəl həmin siyahıya qarşı yoxlanmalıdır.

Seçim etməzdən əvvəl nasazlıq yollarını gəzin

İstifadəçinin rastlayacağı sıra ilə müştəridən qəsdən nasazlıqlar yaradın. İnterfeysdən və onun MTU-sundan başlayın, çünki iç-içəlik autentifikasiyada yox, paket ölçüsündə çox əvvəl sınır.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Sonra qorunma son nöqtələrini fərz etmək yerinə təsdiqləyin. Hansı tunel açıqdırsa, onun içindən xidmətdən sertifikatını istəyin və müştərinin gördüyü zənciri xidmətin həqiqətən təqdim etdiyi zəncirlə müqayisə edin. Yenidən imzalayan və ya müdaxilə edən şlüz həmin sertifikatı dəyişir və yoxlama bir əmrlə görünən olur.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Yenidən qoşulma matrisi ilə bitirin: müştərinin tuneli düşür, B-nin tuneli düşür, A ilə B arasındakı yol dəyişir. Nəyin qayıtdığını, nəyin qayıtmadığını və daxili bağlantının heç vaxt nəzərdə tutulan daşıyıcısından kənar marşruta düşüb-düşmədiyini qeyd edin. Hər testin istifadə etdiyi ünvanları yazın, çünki onu başqa giriş şəbəkəsində təkrarlamaq başqa suala cavab verir. Hər yenidən qoşulmadan sonra MTU yoxlamasını da təkrarlayın, çünki dəyişmiş yol bir konfiqurasiya sətri tərpənmədən istifadə oluna bilən ölçünü aşağı sala bilər.

A daxili paketə siyasət tətbiq etməlidirsə və ya müştəri iki üst-üstə tunel işlədə bilmirsə, ardıcılı seçin. Daxili yük A-da oxunmaz qalmalıdırsa, iç-içəni seçin. Seçimi müşahidəçiləri və MTU rəqəmləri ilə birlikdə yazın ki, növbəti adam bir suala cavab vermək üçün bütün mənzərəni yenidən çəkməsin.