Yaşıl ikon, eyni publik IP: VPN hansı marşrutu atladı

Qoşulub, ikon yaşıldır və ünvanı əks etdirən səhifə hələ də provayderin ünvanını göstərir, bu isə avtomatik nasazlıq demək deyil. Müştəri iki ayrı iş görür: tunel qurur və marşrut cədvəlini dəyişir. Bunlardan biri digəri olmadan da baş verə bilər və seçmə marşrutlaşdırma ikincisinin qəsdən atlandığı konfiqurasiyadır.

Müştəri əslində nə quraşdırdı

Tunelin qalxıb-qalxmadığını soruşmaq əvəzinə, paketi real təyinat yerinə hansı interfeysin daşıyacağını soruşun. Həmin təyinat üçün marşrutu olmayan tunel heç kimin istifadə etmədiyi özəl yoldur.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

Birinci əmr Linux və macOS-da cavab verir, digər ikisi isə Windows ekvivalentləridir və biri kifayətdir. Cavab fiziki adaptörü göstərirsə, tunel qalxıb və standart marşrut heç tərpənməyib. Tuneldən istifadə etməli olan təyinat üçün sorğunu təkrarlayın, çünki iki sorğu, biri uzaq və biri adi, hansı dizaynın tətbiq olunduğunu deyir.

Seçmə marşrutlaşdırmanın üç forması

Tam tunel profili adətən interfeysə baxan standart marşrut yazır və ya prefiks uzunluğuna görə qalib gələn yarımşəbəkə cütünü yazır, orijinal standart isə cədvəldə qalır. Seçmə marşrutlaşdırma digər seçimdir və bir neçə formada olur. Bir profil RDP serveri kimi tək bir hostu marşrutlaşdırır, digəri müəyyən yerdən əldə edilməli olan publik diapazonu, üçüncüsü isə bir tətbiqi qəsdən istisna edir. Üçü də qanunidir və heç biri ümumi saytın gördüyü ünvanı dəyişmir.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Qərar verən direktiv üçün profili, nəticə üçün isə cədvəli oxuyun. Göndərilən direktiv müştəridə də sıxışdırıla bilər, ona görə serveri günahlandırmazdan əvvəl profil və cədvəl uzlaşmalıdır.

Uzaq tərəf mənbə ünvanını yenidən yazmalıdır

Brauzerdən eyni görünən ikinci nasazlıq var. Marşrut tunelə işarə edir, server paketləri alır və sonra onları müştərinin özəl ünvanı toxunulmadan ötürür. Növbəti hopun həmin ünvan üçün qayıdış yolu yoxdur, ona görə cavablar yox olur və səhifələr donur. Server ümumiyyətlə ötürməlidir və mənbəyi internetin geri marşrutlaşdıra biləcəyi bir şeyə tərcümə etməlidir.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

İnternetə həqiqətən baxan interfeysi adlandırın, bu müasir distributivdə həmişə eth0 olmur. Sabit ünvanlı hostinq serveri masquerade əvəzinə birbaşa həmin ünvana tərcümə edə bilər. Hər iki yarım vacibdir, çünki tərcüməsiz ötürmə marşrutsuz mənbələri sızdırır, ötürməsiz tərcümə isə paketi heç görmür.

Ad həlli öz yolunu tutur

Trafik tuneldən çıxa bilər, halbuki adı tapan sorğu yerli şəbəkədəki həll ediciyə gedib. Görünən ünvan eyni qalır, sorğular isə yox, və bu boşluq məhz bölünmüş DNS dizaynının seçdiyi şeydir.

resolvectl status | head -20
resolvectl query example.org

Hansı serverin cavab verdiyini və tuneldən əvvəlki baza ilə fərqlənib-fərqlənmədiyini qeyd edin. Bölünmüş tuneldə bu, adətən insanların ünvandan şikayət edəndə dəyişmək istədikləri ayardır və heç vaxt baxmadıqları ayardır.

Bunu həll edən dörd müşahidə

Çıxış ünvanını tunel bağlı ikən, sonra açıq ikən yazın. Təyinat sorğusunu hər iki vəziyyətdə aparın və hər dəfə interfeysi qeyd edin.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Sorğu tunelin içinə düşəndə və əks etdirmə hələ də provayderin ünvanını göstərəndə, çıxışda tərcümə yoxdur. Sorğu fiziki adaptörə düşəndə profil seçmədir və publik ünvan heç vaxt işin içinə düşməyib. Etdiyinizə güvəndiyiniz əks etdirmə xidməti ilə dəyişdirin və dörd müşahidəni birlikdə yazın, çünki ayrı-ayrılıqda onlar anekdotdur. Birlikdə isə müştərinin iki işdən hansını həqiqətən yerinə yetirdiyini göstərir.