OpenVPN müştərisinin trafikini şlüzda haradan izləmək olar

Bağlı müştərinin hansı ünvanlara çatdığını bilmək istəyirsiniz, ona görə VPN serverində qabıq açıb ss yazırsınız. Faydalı heç nə görünmür və tunelin xarab olduğu qənaəti bir qədər çox asanlıqla gəlir. Marşrutlaşdıran OpenVPN şlüzü müştərinin paketlərini ötürür; onların TCP bağlantılarını sonlandırmır və onlar üçün soketə sahib olmur. Sübut başqa yerdə yaşayır və hansı yerdə olduğu trafikin tuneldən çıxdıqdan sonra necə idarə olunduğundan asılıdır.

Hansı quruluşa baxdığınızı müəyyən edin

İki geniş yayılmış forma tamamilə fərqli sübut verir. Marşrutlaşdıran şlüz dekapsulyasiya edir, ötürür və bəlkə mənbə NAT tətbiq edir, buna görə müştərinin bağlantısı yerli soket olmadan başdan-başa mövcud qalır.

Proksi trafiki sonlandırır: bağlantını qəbul edir, sonra öz yuxarı bağlantısını açır. Bu quruluşda bir sorğu üçün iki bağlantı var və onlar arasındakı əlaqə yalnız proksinin öz qeydlərində mövcuddur. Bunlardan hansını yerləşdirdiyinizi bilmək nüvənin axın vəziyyətini, yoxsa tətbiq jurnallarını oxumalı olduğunuzu müəyyən edir.

Qarışıqlığın çoxu təxmin etməkdən gəlir. Aləti seçməzdən əvvəl formanı təsdiqləyin. Əvvəlcə server konfiqurasiyasında proksi direktivini axtarın, çünki onun olması bütün sonrakı addımları dəyişir. O olmadan paket yolu marşrutlaşdırmadır və nüvənin axın vəziyyəti sizin sübutunuzdur.

Əvvəlcə ünvanı sessiyaya bağlayın

Serverin sessiya vəziyyətindən başlayın və müştərinin cari daxili ünvanını müəyyən edin. Hovuz ünvanları təkrar istifadə olunur, buna görə ünvan təkbaşına icarədir, şəxs deyil.

Vaxtı və təsdiqlənmiş kimliyi birlikdə qeyd edin və həmin müştərinin arxasında bütöv bir yerli şəbəkənin gizləndiyini qeyd edin. Uzaq tərəf alt şəbəkəni marşrutlaşdırırsa, gördüyünüz daxili ünvanlar ilkin hostlar və ya çevrilmiş olanlar ola bilər.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Bu cüt eyni anda iki suala cavab verir: tunel interfeysi hansı prefiksi xidmət edir və maraqlandığınız intervalda hansı sessiya aktiv idi. Hər hansı axın qeydini şərh etməzdən əvvəl bunu edin, çünki səhv sessiyaya bağlanmış inandırıcı bir dəst heç bir sübutdan pisdir.

Marşrutlaşdıran şlüzda axın cədvəlini oxuyun

Ünvan və interval müəyyən edildikdən sonra izlənən bağlantıların yalnız oxuma üçün siyahısı şlüzün onun üçün nə ötürdüyünü göstərir. İlkin mənbə üzrə filtr edin ki, bütün cədvəli oxumayasınız.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Hər qeyd iki dəst saxlayır, ilkin və cavab, bunlar iki tətbiq deyil, bir axının iki istiqamətidir. Mənbə NAT yolunda ilkin dəst tunel ünvanını saxlayır, cavab tərəfi isə çevrilmiş şlüz ünvanını göstərir və çıxışın ilk baxışda səhv görünməsinin səbəbi məhz budur.

Siyahıya tarix kimi deyil, canlı vəziyyət kimi baxın. Qısa axınlar artıq bitmiş ola bilər, izlənməyən trafik heç vaxt görünmür və fərqli şəbəkə adlar məkanı fərqli cədvəl göstərir. conntrack sənədi filtrləri və ikiistiqamətli çıxışı sənədləşdirir.

Oxunuşu təsdiqləmək üçün bir məhdud çəkiliş

Tunel interfeysi baxdığınız yerdə görünürsə, tək bir məhdud çəkiliş müəyyən etdiyiniz paketlərin naqildə olanlar olub-olmadığını həll edir. Filtri dar, paket limitini kiçik saxlayın.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Vaxt möhürlərini, protokolu və portları axın qeydi ilə və test kimi etdiyiniz sorğu ilə müqayisə edin. NAT-dan sonra götürülmüş çəkiliş yalnız şlüzün ictimai ünvanını göstərir, tunel tərəfi isə hələ də müştərininkini göstərə bilər və bu fərq uyğunsuzluq deyil, məlumatdır.

Interfeys heç nə görmürsə, müştərinin boş olduğu qənaətinə gəlməzdən əvvəl məlumat yolunu yoxlayın: müştəridən müştəriyə trafik və bəzi boşaltma yolları izlədiyiniz nöqtədən heç vaxt keçmir.

Proksi jurnalları və gördüklərinizin hüdudları

Proksi yolda olduqda onun yuxarı soketləri soket cədvəlində görünür, lakin onlar VPN müştəriləri ilə birə-bir uyğunlaşmır, xüsusilə hovuzlaşdırma və ya multipleksləmə ilə. Müştəri kimliyini, təyinatı, vaxt möhürünü və qeyd etdiyi hər hansı sorğu identifikatorunu əlaqələndirmək üçün proksinin konfiqurasiya edilmiş əməliyyat jurnalından istifadə edin.

Hər sorğunun susmaya görə jurnala yazıldığını fərz etmək əvəzinə yerləşdirilmiş versiyanın jurnallaşdırma konfiqurasiyasını yoxlayın.

Nəhayət, əhatə dairəsi barədə dəqiq olun. Təyinat ünvanı və port metadata-dır, URL deyil və səhifə məzmunu deyil, çünki daxili HTTPS sessiyası tuneldən asılı olmayaraq öz müdafiəsini saxlayır. Nə müşahidə etdiyinizi, hansı müşahidə nöqtəsindən və hansı vaxtda olduğunu bildirin.