Trafik həqiqətən VPN-dən keçirmi? Bunu necə yoxlamaq olar

İki nasazlıq sistem çubuğu ikonundan eyni görünür: tunelə girən trafik və onun ətrafından sakitcə keçən trafik. Müştəri hər iki halda Connected göstərir, çünki Connected yalnız tunel interfeysinin mövcud olduğunu və müştərinin istədiyi marşrutları quraşdırdığını bildirir. Bir tətbiqin bir paketinin həmin marşrutlardan istifadə edib-etmədiyi ayrı sualdır və steqin başqa yerində cavablandırılır. Dörd ölçmə işin çoxunu həll edir — marşrut axtarışı, ilk atlama, fiziki adapterdə tutma və kənardan müşahidə — serverin öz sessiya görünüşü isə qalanını əhatə edir.

Paketin gedəcəyi marşrutla başlayın

Marşrut cədvəli qərardır, ona görə hamısını oxuyub təxmin etmək əvəzinə bir təyinat haqqında soruşun. Linux-da ip route get kernin seçdiyi interfeysi və mənbə ünvanını göstərir:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windows-da Find-NetRoute -RemoteIPAddress 203.0.113.10 eyni səbəbdən route print -4-dən daha faydalıdır: qalib gələn marşrutu bildirir, mövcud olan bütün marşrutları yox. Yenə də cədvəli bir dəfə onun 0.0.0.0 sətri üçün oxuyun. Orada /1 cütü tam tunel müştərisinin defoltu yenidən yazdığını göstərir: OpenVPN-in redirect-gateway def1 seçimi tunel vasitəsilə 0.0.0.0/1 və 128.0.0.0/1 quraşdırır və bu, fiziki defoltu silmədən ən uzun prefiks uyğunluğunda mövcud 0.0.0.0/0-u üstələyir. Buna görə iki defolt birlikdə mövcud ola bilər, halbuki hər şey yenə tunelə girir.

Cədvəli yalançı edən iki detall var. Birincisi, defolt marşrutların sayına deyil, uyğun gələn prefiksə baxın, çünki qalibi interfeys metrikanı və ya /1 cütü həll edir. İkincisi, artıq mövcud olan bağlantı qurulduğu yolu saxlayır; tunel qalxdıqdan sonra açıq sessiya sıfırlanana qədər köhnə marşrutu işlədə bilər, buna görə yenidən qoşulma marşrut problemini həll edirmiş kimi görünür. İşləyən müştəri — ps ax | grep openvpn — yalnız prosesin başladığını sübut edir.

Bir daxili və bir ictimai adı izləyin

Marşrut axtarışı niyyəti göstərir; yol isə çatdırılmanı. Qoşulmuş halda mütləq daxili olan bir adı və mütləq olmayan bir adı izləyin və ilk atlamanı müqayisə edin:

traceroute intranet.corp.example
traceroute 1.1.1.1

Hər ikisi üçün eyni ilk atlama daxili adın heç vaxt tunelə girmədiyini və nasazlığın ondan yuxarıda olduğunu bildirir; adətən bu, ictimai ünvana həll olunan ad və ya heç quraşdırılmamış marşrutdur. Daxili trafik 10.8.0.1-dən çıxarkən ictimai trafik 192.168.1.1-dən çıxırsa, bölünmüş tunel məhz konfiqurasiya edildiyi işi görür. VPN şlüzünə çatıb sonra yalnız timeout qaytaran iz adətən geri yol və ya server firewall problemi olur, çatışmayan irəli marşrut deyil.

Filtrlənmiş ICMP bu yoxlamanı yalançı edir: hər iki izdə ulduzlar ölü tunel kimi görünür və adətən bu firewall-dır. Mümkün yerdə TCP portunu yoxlayın — Linux-da traceroute -T -p 443 — və yadda saxlayın ki, iz hansı həlledicinin cavab verdiyini demir: ad lokal həll oluna və yenə tuneldən keçə bilər.

Tuneldə deyil, fiziki adapterdə tutun

Fiziki əlaqə şəbəkənin həqiqətən nə gördüyünü göstərən yeganə yerdir. Tunel qalxmış halda ofisə sessiya 10.20.5.7-ə bağlantı kimi deyil, VPN serverinə ünvanlanmış şifrələnmiş yük kimi görünməlidir:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Birinci filtr lokaldan çıxan ad həllini tutur; bu, ən çox yayılan və ən səssiz sızmadır — səhifə yenə açılır, sadəcə həlledici sorğunu görüb. İkinci filtr yalnız tunelin içində mövcud olmalı daxili ünvana gedən adi trafiki tutur. Windows-da pktmon eyni işi sürücü olmadan görür: pktmon filter add -p 53, sonra pktmon start --capture --pkt-size 128, sonra pktmon stop və pktmon format pktmon.etl -o capture.txt. Bu bayraqlar Windows buraxılışları arasında bir az fərqlənir, ona görə sintaksisə güvənməzdən əvvəl pktmon filter add /? yoxlayın.

Sızmaları tapmaq üçün fiziki interfeysdə tutun; tuneldə tutma artıq orada olduğuna inandığınız paketləri ehtiva edir, serverdə isə mənbəyi şlüz olan oxunmaz xarici paketləri ehtiva edir. Hər iki interfeysdə bayt sayğacları paketləri təsvir edir, proqramları yox; trafiki prosesə aid etmək üçün soketləri proseslərə bağlayan monitor lazımdır.

Kənar xidmətdən soruşun, sonra hər tətbiq üçün yenidən soruşun

Çıxışı sübut edən yeganə yoxlama kənardan gələn cavabdır: gördüyü mənbə ünvanını geri qaytaran xidmət. Onu interfeysi seçə bildiyiniz qabıqdan işə salın və iki dəfə işə salın:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Fərqli cavablar hər iki yolun sübutunu və konkret tətbiqi yoxlamaq imkanını verir: onu bağlayın və ya bir marşrutlu şəbəkə ad məkanında işə salın və uzaq tərəfin hansı ünvanı qeyd etdiyinə baxın. Eyni cavablar maraqlı nasazlıqdır: ya bağlama qüvvəyə minməyib, ya da hostla uzaq tərəf arasında nəsə mənbə ünvanını çatmazdan əvvəl yenidən yazır. Windows-da curl --interface adapterin adını deyil, ünvanını istəyir.

VPN ünvanını göstərən brauzer brauzeri sübut edir. Poçt müştərisi, paket meneceri, ehtiyat nüsxə agenti və ya ikinci brauzer profili hər biri fərqli yol tuta bilər, xüsusən proxy ayarı və ya bölünmüş tunel marşrutu onlardan birini əhatə edəndə. Ünvan dəyişikliyi təkbaşına sızma sübutu deyil: balanslaşdırıcı gördüyü çıxışa görə fərqli cavab verə bilər, ona görə səhifəni deyil, qeydə alınan mənbə ünvanını müqayisə edin.

Peer-i təsdiqləmək üçün server görünüşündən istifadə edin

Server başqa suala cavab verir: peer qoşulubmu, nə qədər daşıyıb və sessiya yenidən başlayıbmı. Serverdə peer işlək vəziyyətdədirsə, müştəri sayğacları isə demək olar tərpənmirsə, bu, tətbiq trafikinin tunelə girmədiyini göstərir, müştəri cədvəli nə deyirdisə də. Heç nə işləmədiyini bildirən istifadəçi üçün çoxlu data daşıyan peer isə başqa araşdırmadır.

Burada iki tələ var. Maskalanmış tunel hər axını şlüzdən gələn kimi göstərir, buna görə jurnallar və hər müştəri üzrə hesablamalar bir ünvanda yığılır. Müştəri isə lokal host kimi qəbul edilir, yəni kiminsə VPN ilə fayl köçürməsi sualına serverdə fayl paylaşımı trafiki və ya serverdə host audit cavab verir — tunelə baxmaq son nöqtələri və həcmi verir, fayl adlarını yox.

Dizayn qərarını sızma ilə ayırd edin

Tuneldən kənarda olan hər şey sızma deyil. Link-local və yayım trafiki dizayna görə lokaldır, multicast ilə tapılan printer LAN-da elanını davam etdirir, DHCP isə lokaldan çıxmalıdır. Konkret interfeysə bağlanmış tətbiq marşrut cədvəlini bilərəkdən yan keçir, bunu yalnız firewall qaydası, ad məkanı və ya siyasət marşrutu dəyişir.

IPv6 yoxlama siyahısında öz sətrini layiq görür. Yalnız IPv4 daşıyan tunel ikili stekli hostda ikinci istifadə edilə bilən yol buraxır və ikili stekli hədəf onu üstün tutacaq — DNS də daxil, əgər həlledici IPv6 ilə əlçatandırsa. IPv4 nəticəsini tam saymazdan əvvəl adapterdə IPv6-nı söndürün və ya tunelin onu daşıdığını təsdiqləyin.

Yoxlamalar ziddiyyət təşkil edəndə, ziddiyyət adətən nasazlığı adlandırır:

İşləyən ardıcıllıq: qoşulmadan əvvəl və sonra marşrut cədvəlini saxlayın, bir daxili və bir ictimai adı izləyin, fiziki adapterdə DNS tutun, konkret tətbiq üçün qabıqdan çıxış ünvanını qaytarın, sonra həcm üçün serveri oxuyun. İlk dördü razılaşırsa, tunel düşündüyünüzü daşıyır və qalan problem ondan yuxarıdadır. İkisi ziddiyyət təşkil edirsə, ziddiyyət təşkil edən cüt nasazlıqdır, ikon yox.