Eyni hostda NGINX və OpenVPN quruluşunda üç müştəri ünvanı görünür, hər biri sorğunun gedə biləcəyi bir yol üçün. Tunel ünvanına müraciət edən brauzer, açıq ünvana müraciət edən brauzer və şlüzün internet yolundan çıxan proqram dinləyici soketdə tamamilə fərqli görünür. Jurnal sətrini şərh etməzdən əvvəl hansı yola baxdığınızı müəyyən edin. Qərar müştərinin istifadə etdiyi təyinatdan, onun xarici VPN son nöqtəsi üçün saxladığı istisnadan və paketin yolda hər hansı tərcüməyə məruz qalıb-qalmadığından asılıdır.

İstifadəçinin kimliyinə görə deyil, təyinata görə qərar verin

Sorğunun göndərildiyi ünvandan başlayın, çünki yolu məhz həmin ünvan seçir. Hostun tunel ünvanına olan sorğu tunel interfeysinə müştərinin daxili ünvanını mənbə kimi gətirir. Hostun açıq ünvanına olan sorğu adətən internetə baxan interfeysə müştərinin açıq ünvanı ilə gəlir, hətta həmin noutbukda o anda tunel qurulmuş olsa belə. Buna görə VPN hovuzuna aidlik paket yolunun xassəsidir, istifadəçinin arxasınca gələn xassə deyil.

Path the request tookSource the site normally records
Client reaches the site at its tunnel address, 10.24.0.1Client inner address, 10.24.0.20
Client reaches another internet site through the gatewayGateway public egress address, 192.0.2.44
Client reaches the gateway's public address through the endpoint exceptionClient's own public access address

Jurnalda tunellə heç bir əlaqəsi olmayan ünvanla görünən VPN istifadəçisi olduqda ilk yoxlanmalı sətir məhz bu üçüncü sətirdir. Bu, həm də izah edir ki, niyə eyni profildə olan iki istifadəçi fərqli qeydlər yarada bilər: onların öz giriş şəbəkələri fərqlidir və tuneldə heç nə bunu üzərinə yazmır.

Niyə xarici son nöqtə ikinci açıq yol yaradır

Müştəri tuneli qurmaq üçün şlüzün açıq ünvanına çatmalıdır, ona görə həmin ünvana gedən marşrut tuneldən kənarda mövcud olmalıdır. Müştəri bütün trafiki içəri yönəltdikdə, ağlabatan tətbiq özündən asılı olan tuneldən qaçmaq üçün serverin açıq ünvanı üçün açıq host marşrutu saxlayır. Bu istisna xidmətlərə görə seçici deyil, ona görə eyni açıq ünvana hər hansı sorğu ona əməl edir, o cümlədən şlüzdə yerləşən sayta brauzer sorğusu.

Bu, bu sahədə ən qarışıq hesabatların arxasındakı mexanizmdir və serverə görə deyil, müştəri tətbiqinə görədir. Buna görə eyni profilə malik iki müştəri fərqli davrana bilər. Jurnalı »düzəltmək« üçün istisnanı silmək tuneli də onunla birlikdə söndürür, ona görə onu saxlayın və ətrafında dizayn edin.

Soketi, cədvəli və jurnal formatını birlikdə oxuyun

Üç müşahidə hansı yola baxdığınızı həll edir: soketin harada dinlədiyi, təyinatı hansı interfeysin cavablandırdığı və jurnal formatının həqiqətən nə qeyd etdiyi. Əgər dinləyici yalnız tunel ünvanına bağlanıbsa, açıq sorğu ona ümumiyyətlə çata bilməz, bu da iki sətri dərhal istisna edir. Müştəri üçün axtarış tunel cihazını qaytarırsa, sorğu daxili mənbə ilə gəlib və jurnal bunu göstərməlidir.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Sonra sətri deyil, formatı oxuyun. Yönləndirilmiş başlıqla qidalanan sahə soket qarşı tərəfini deyil, bir iddianı qeyd edir və bu iddia yalnız birbaşa qarşı tərəf etibarlı proksi olduqda əhəmiyyət kəsb edir. Hər iki dəyəri jurnala yazmaq sonrakı mübahisələri həll edir, çünki birbaşa qarşı tərəf və əvəzlənmiş ünvan fərqli faktlardır və onlardan yalnız biri şəbəkədən gəlib.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

İstədiyiniz giriş nöqtəsini seçin və DNS-i uyğunlaşdırın

Sayt yalnız tuneldən əlçatan olmalıdırsa, ona VPN müştəriləri üçün tunel ünvanına çevrilən ad verin və dinləyici soketdə siyasət tətbiq edin. Daxili ad üçün 10.24.0.1 qaytaran split-DNS cavabı ad həlli detallarının libasında bir marşrut qərarıdır. Sayt həm də açıq olmalıdırsa, iki ad və ya iki port saxlayın və hansının sorğuya xidmət etdiyini jurnal söyləsin.

İcazə qaydaları eyni məntiqi izləyir. Tunel hovuzuna icazə vermək açıq sorğunu səlahiyyətləndirmir və internetdən gələn bağlantıda daxili ünvan yaratmır. Hər iki giriş nöqtəsini bir ad altında qarışdırmaq qeydə alınan mənbəyi dizayn seçimi deyil, müştəri marşrutlaşdırmasının yan təsirinə çevirir.

Əvvəlcə yolu, sonra siyasəti yoxlayın

Yolu şlüzdə çəkiliş və nəzarət etdiyiniz sorğu ilə təsdiqləyin. Tunel cihazında və açıq interfeysdə çəkiliş baytları hansının daşıdığını göstərir, paketlərin sırası isə aralarında tərcümənin olub-olmadığını söyləyir.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Sonra girişi hər iki istiqamətdə yoxlayın: nəzərdə tutulan adlı giriş nəzərdə tutulan müştəri üçün işləyir və icazəsiz açıq yol sadəcə yavaş deyil, rədd edilir. Ümumi IP-echo saytı şlüzün internet çıxışı haqqında bir şey sübut edir və bu eyni hostdakı sayt haqqında heç nə. Səhifə ilə WebSocket fərqli fikirdə olduqda, server konfiqurasiyasına toxunmazdan əvvəl onların URL-lərini, ünvan ailələrini və DNS cavablarını müqayisə edin.

Əlaqəli məqalələr