OpenVPN tam tuneli SSH sessiyanızı kəsir: cavab yolunu düzəldin

SSH ilə qoşulduğunuz maşında tam tunelli OpenVPN müştərisini işə salmaq sessiyanı bir saniyə içində kəsə bilər və maşın heç bir səhv etmir. Tunel paketlərin serverə çatma üsulunu deyil, cavabların necə çıxdığını dəyişir. Defolt marşrut tun0-a baxdıqdan sonra SSH müştərinizə gedən cavab provayderin şəbəkəsinə düşür və o şəbəkənin sizin ünvanınıza geri marşrutu yoxdur. Bağlantı asılır, növbəti cəhd vaxt aşımına uğrayır və daemon bütün bu müddətdə 22 portunda dinləməyə davam edir.

VPN jurnalını oxumazdan əvvəl marşrut cədvəlini oxuyun. Jurnal tunelin qalxdığını deyəcək və haqlıdır. Sual hər cavabın hansı interfeysə verildiyidir və bu, tunelin indicə yenidən yazdığı cədvələ qarşı hər paket üzrə axtarışdır.

Cavab niyə səhv qapıdan çıxır

Daxil olan paketlər hələ də fiziki interfeysə gəlir, çünki VPN müştərisi internetin serverinizin ümumi ünvanına çatma üsulunu dəyişə bilməz. Cavablar ayrı qərardır: hər paket üçün nüvə təyinatı axtarır və --redirect-gateway-dan sonra defolt giriş tunel deyir. Provayderin çıxışı xidmət etmədiyi təyinatı görür və paketi atır.

OpenVPN-in öz qoruması tam olaraq bir təyinatı əhatə edir. 2.6 təlimatı --redirect-gateway seçimini ardıcıllıq kimi təsvir edir: tuneldən əvvəl istifadə olunan şlüz vasitəsilə VPN peer-i üçün host marşrutu əlavə edir ki, şifrələnmiş trafik öz içinə dönməsin, sonra defolt marşrutu əvəz edir. Bu host marşrutu yalnız peer üçündür. SSH müştəriniz sadəcə başqa bir internet ünvanıdır və heç bir istisna almır.

Bir prefiks səhvini erkən istisna etmək lazımdır. Uzunluq olmadan ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 əmri tək 0.0.0.0 ünvanına uyğun gəlir, internetə yox; 0.0.0.0/0 olmalıdır. Və əgər defoltu qəbul etmək tunelin öz nəqliyyatını pozursa, son nöqtəni fiziki interfeys vasitəsilə host marşrutu kimi əlavə edin, provayderin real ünvanı ilə.

Dərhal həll üçün SSH müştəri ünvanınızı bağlayın

Ən sürətli düzəliş müştəri ünvanınız üçün tuneldən əvvəl serverin istifadə etdiyi şlüz vasitəsilə host marşrutudur. Öz tərəfinizdən serverin görəcəyi ünvanı tapın, sonra köhnə şlüzü bilmək üçün serverin cədvəlini oxuyun:

curl -s https://ifconfig.co
ip route

Serverdə istisnanı müştəri başlamazdan əvvəl əlavə edin. Buradakı ünvanlar yer tutucudur; vacib olan formadır:

sudo ip route add 80.128.240.55 via 192.168.178.1

Bu, bildirilən halda istifadə olunan düzəlişdir və dərhal işləyir. O, həm də iki proqnozlaşdırıla bilən şəkildə kövrəkdir: marşrut yenidən başlatmada yox olur və ISP sizə fərqli ünvan verdiyi anda səhv olur. Onu fövqəladə tədbir kimi qəbul edin və qəsdən davamlı edin, şəbəkə vahidi və ya dispatcher qarmağı ilə, ya da müvəqqəti olduğunu qəbul edib bərpa yolunu yazın.

Müştərinin defoltu götürməsinin qarşısını alın

Daha təmiz variant tunelin defolt marşrutu ümumiyyətlə əvəz etməsinə imkan verməməkdir. route-nopull, --client və ya --pull ilə birlikdə istifadə edildikdə, marşrutlar, block-outside-dns və DNS serverləri kimi DHCP tipli seçimlər istisna olmaqla göndərilən seçimləri qəbul edir, beləliklə yalnız lazım olan prefiksləri əlavə edirsiniz. Daha dar alət çəkmə süzgəcidir: bir problemli direktivi atır, qalanını saxlayır:

route-nopull
pull-filter ignore "redirect-gateway"

Birini və ya digərini istifadə edin, ikisini yox, və nəyin dəyişdiyini dəqiq bilin. Tuneldən defolt marşrut olmadıqda server artıq internetə provayder vasitəsilə baxmır; yalnız açıq şəkildə marşrutlaşdırdığınıza çatır. Əgər tam tunel quraşdırmanın bütün məqsədi idisə, bu səhv düymədir və yuxarıdakı host marşrutu düzgündür.

Qayıdış yolunu mənbəyə və ya bağlantıya görə bölün

Gələn ünvan sabit olduqda, mənbə qaydası tunelin öz marşrutlarına toxunmadan cavabları yerli saxlayır. Fiziki interfeys ünvanına LAN prefiksini və fiziki defoltu olan öz cədvəlini verin, sonra ondan qaynaqlanan trafik üçün həmin cədvəli seçin:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

Bu işləyir, çünki gələn SSH bağlantısına cavablar müştərinin qoşulduğu ünvandan qaynaqlanır. Hər gələn xidmətin işləməyə davam etməli olduğu bildirilən hal məhz bu formadan istifadə etmişdi. Gələn ünvan üzəndə və ya yol dinamik olduqda, bunun əvəzinə bağlantını işarələyin: fiziki interfeysdən gələn ilk paketə conntrack işarəsi qoyun, onu OUTPUT-da cavab paketlərinə köçürün və işarələnmiş paketləri fiziki şlüzə yönələn cədvəldən keçirin.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Test edərkən bağlantı işarəsini, firewall işarəsini və cədvəl nömrəsini fərqli saxlayın. Bir nömrəni iki rol üçün təkrar istifadə etmək düzgün görünən və səhv paketlərə uyğun gələn qayda yaradır. Cədvəlin defolt girişi də adi Ethernet keçidində LAN şlüzü ilə via tələb edir; çılpaq dev eth0 defoltu yalnız interfeys nöqtədən-nöqtəyə olduqda və ya növbəti hop başqa cür həll edildikdə işləyir. Bildirilən Jessie hostu təsadüfən çılpaq formanın işlədiyi bir keçiddə idi və bu, kopyalanacaq distribusiya qaydası deyil.

Özünüzü kilidləmədən yoxlayın

Bağlantını kəsərək test etməyin. İlk sessiyanı açıq saxlayın, tuneli qaldırın və nüvədən öz ünvanınızın hansı yolu tutacağını soruşun:

ip route get 80.128.240.55

Cavab tuneli deyil, fiziki interfeysi və köhnə şlüzü adlandırmalıdır. Sonra ikinci SSH bağlantısı açın; əsl sınaq budur, çünki köhnə sessiya yeni bağlantının təkrar yarada bilmədiyi vəziyyət üzərində qala bilər. Əgər ikinci asılır, birinci hələ cavab verirsə, qayda vacib trafikə heç vaxt uyğun gəlməyib və baxmalı olduğunuz yer işarələr və ya mənbə ünvanıdır.

Bütün məşq boyu bantdankənar konsol əlçatan saxlayın. Yeganə giriş yolu indicə pozduğunuz tunel olan serveri həmin tunel üzərindən bərpa etmək mümkün deyil və əlavə etdiyiniz cədvəl nömrələrini və prefiksləri yazdığınızda geri qaytarma daha asan olur.