Niyə ikinci VPN tuneli birincini sındırır?

Bir müştəri şəbəkəsinə çatmaq üçün ikinci VPN klienti quraşdırmaq bunun adətən başladığı yoldur və hər iki klient uğur bildirərkən birinci tunel qaralır. Hər klient standart marşrut quraşdırdı, ikincisi daha dəqiq idi, və nüvə indi birinci tunelin öz xarici bağlantısından başqa hər şey üçün onu izləyir. Heç nə çökmədi və heç bir profil səhv deyil. Bir marşrut digərini əvəz etdi və həll standart marşrutun hansı tunelə məxsus olacağını qərarlaşdırmaqdır.

Simptom: ikinci klient səssizcə qazanır

OpenVPN: redirect-gateway def1 parametri 0.0.0.0/0-i əvəz etmir. O, 0.0.0.0/1 və 128.0.0.0/1 əlavə edir: birlikdə bütün IPv4 ünvanlarını əhatə edir və hər prefiks uzunluğuna görə adi standart marşrutu üstələyir. İlkin standart marşrut cədvəldə qalır və adi trafik üçün istifadə olunmaqdan çıxır, VPN serverinə host marşrutu isə tunelin öz xarici paketlərini tutmasının qarşısını alır. Hər iki klient bunu edir və ikincisi sadəcə öz cütünü sonra quraşdırır.

Buna görə birinci tunel qopmuş deyil, ölü görünür. İnterfeysi işləyir, idarə kanalı canlıdır və ona artıq heç bir tətbiq trafiki çatmır. Əks şikayət də eyni çatışmayan push-dan qaynaqlanır: qoşulan lakin heç nə göndərməyən telefon adətən redirect-gateway elan etməyən serverlə danışır, ona görə cihaz öz standart marşrutunu saxlayır və yalnız hovuza çatır.

İkinci klient qoşulmazdan əvvəl və sonra marşrut şəkli çəkin. Cədvəldə görünən iki yarım marşrut bütün dəyişiklikdir və hər iki şikayəti izah edir. Simptomun görünməsi üçün cədvəldə başqa heç nə yer dəyişməməlidir. Buna görə də ikinci klientin silinməsi birincini dərhal bərpa edir.

Hansı tunelin həqiqətən qazandığını oxuyun

Qalibi klientlərin başlama sırasından və ya sistem tepsisindəki işarədən çıxarmayın. Nüvədən hər iki özəl şəbəkədən kənar bir təyinat üçün hansı marşrutu istifadə edəcəyini soruşun və geri qaytarılan interfeysi oxuyun.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

İlk ikisi Linux cavabı, son ikisi isə Windows ekvivalentidir. Onları hər iki tunel işləyərkən icra edin, sonra birini ayırın və yenidən icra edin. İki çıxış arasındakı fərq həll seçməzdən əvvəl lazım olan faktdır və hər hansı klientin jurnalını oxumaqdan az vaxt aparır.

Nəticəni interfeys adı və uyğun gələn prefiks daxil olmaqla qeyd edin. İkinci VPN birincini sındırdı deyən bilet simptomun təsviridir, heç kimin üzərində işləyə biləcəyi marşrut ifadəsi deyil. Axtarış onu növbəti mühəndisin bir əmrlə təkrarlaya biləcəyi fakta çevirir.

Windows: bir profilin standart marşruta sahib olmasının qarşısını alın

Windows saxlanmış profilləri saxlayır və daxili klient birinin digərindən asılı olmasına imkan verir ki, ikinci qoşulanda birinci avtomatik qalxsın. Ən son qoşulan profil standart marşruta sahib olmağa meyllidir, ona görə praktik sahib birinci deyil, son qoşulmadır. Hər profilə öz push marşrutlarını verin və standart marşruta sahib olmamalı olan üçün bölünmüş tuneli aktivləşdirin.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Bölünmüş tunel bunu dəyişir: cədvələ yalnız server tərəfindən push edilən prefikslər düşür və bu, standart marşrutu birinci tuneldə saxlayır. Dizayn yenə də uğursuz olur, çünki hər iki server standart marşrut push edərsə, son bağlantı qazanır və heç bir klient tərəfi parametri bunu dəyişmir. Server tərəfindəki push-u düzəldin və ya bir sahibi qəbul edin.

Tətbiqlə işə salınan profillər fərqli xüsusiyyətdir və bilməyə dəyər: Windows profili adlandırılmış icra faylı başladıqda işə düşə bilər, trafik filtrləri isə nə daşıyacağını müəyyən edir. Bu, firewall qaydası deyil, profil parametridir və standart marşrut münaqişəsindən fərqli problemi həll edir.

Linux: ikinci tuneli əsas cədvəldən kənarda saxlayın

Bir maşında iki openvpn --config nüsxəsi işlətmək hər iki klienti eyni cədvələ salır və üç seçim onları artan təcridlə ayırır. Ən yüngülü ikinci klientin cədvəli ümumiyyətlə redaktə etməsini dayandırmaqdır: route-nopull və açıq marşrutlar, ya da yalnız nəzərdə tutduğunuzu quraşdıran route-up skripti. Sonra ikinci tunel yalnız adını çəkdiyiniz prefiksləri daşıyır və başqa heç nə daşımır. Sonra hansı prefiksin hara getdiyini sonradan kəşf etmək əvəzinə özünüz qərarlaşdırırsınız.

Siyasət əsaslı marşrutlaşdırma orta seçimdir. Bir qayda tək mənbə ünvanı və ya firewall işarəsi üçün ayrı cədvəl seçir və həmin cədvəl ikinci tunelin marşrutlarını daşıyır. Əks yol filtrləmə burada tələdir, çünki cədvəlin seçəcəyindən fərqli interfeysə gələn cavab atılır, ona görə tunelin xarab olduğu qənaətinə gəlməzdən əvvəl rp_filter parametrini yoxlayın.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Şəbəkə ad sahələri ən ağır və ən təmiz seçimdir. İkinci klienti ip netns içində başladın, ona veth cütü verin və istifadə etmək üçün həmin ad sahəsinə girin. Müdaxilə yox olur, çünki hər ad sahəsi bir cədvəli paylaşmaq əvəzinə öz cədvəllərinə sahibdir; hər iki tunel həftələrlə açıq qalmalı olduqda bu əlavə quruluşa dəyər.

Tətbiq üzrə və ayrı problem kimi zəncirləmə

Bəzən ikinci tuneli yalnız bir proqram istifadə etməlidir. Linuxda istifadəçi, cgroup və ya port üzrə siyasət marşrutlaşdırması bu nəticəyə çatır və tək bir təyinat standart marşruta heç toxunmadan interfeysə bağlana bilər. Soketini bir interfeysə bağlayan tətbiq marşrut cədvəlinə heç müraciət etmir, ona görə başladıcı öz parametrlərində ünvan seçilməyincə fiziki adapterdən istifadə etməyə davam edə bilər.

Zəncirləmə iki tuneli yan-yana işlətməkdən fərqli əməliyyatdır. A-nı B üzərindən zəncirləmək daxili serverin ünvanının xarici tunelin içindən əlçatan olması deməkdir. Xarici klient də daxili klientin şifrələnmiş paketlərini sızma kimi qəbul etməməlidir. Virtual maşın içində bir klient kobud amma etibarlı versiyadır; hər ikisinin bir hostda olması yuxarıdakı marşrut işini üstəgəl daxili serverə doğru heç vaxt daxili tunelə girməyən xarici yol tələb edir.

Standart marşrutun sahibini, hər tunelin daşıdığı prefiks siyahısını və DNS yolunu yazın. Bu üç fakt növbəti hadisəni araşdırma əvəzinə axtarışa çevirir.