Uzaq istifadəçilər VPN mərkəzindən ikinci sayta çata bilmir

Uzaq istifadəçi mərkəzə qoşulur, mərkəzin öz LAN-ındakı fayl serverinə çatır və hər şey sağlam görünür. Sonra qərargahdakı 10.20.0.50 ünvanında bir paylaşım açır, mərkəz ona ayrı bir sayt-sayt tuneli ilə çatır, və vaxt aşımı baş verir. Hər iki tunel işləyir və hər iki sayğac artır, yəni heç bir tunel sınıq deyil. Mərkəzi keçmək üç cihazda üç marşrut qərarıdır və tunel yalnız onun üçün qurulduğu prefiksləri daşıyır. Budur yoxladığım sıra və hər addımın doğru olub-olmadığını göstərən əmr.

Keçid bir tunel deyil, üç axtarış tələb edir

Hər cihaz öz ən-uzun-prefiks uyğunluğunu edir və onu unudur. Noutbuk 10.20.0.50-ni yerli marşrutlaşdırıcısına deyil, tunelə göndərməlidir. Mərkəz uzaq giriş interfeysində gələn paketi sayt-sayt interfeysinə verməlidir. Qərargah istifadəçinin ünvanı üçün cavabı tuneldən geri göndərməlidir. Üçündən hər hansı birinin uğursuzluğu brauzerdə eyni görünür: sükut.

Buna görə hər tuneli tək yoxlamaq bu qədər az şey sübut edir. Mərkəzin LAN ünvanını pingləmək birinci qərarı, mərkəzi qərargahdan pingləmək üçüncünü işə salır. Uğursuz olan paketin mənbəyi istifadəçi hovuzu, təyinatı ikinci saytdır, ona görə əvvəlcə bu prefiksləri yazın. Burada hovuz 10.80.0.0/24, mərkəzin LAN-ı 10.10.0.0/24 və qərargah 10.20.0.0/24-dür.

Uzaq prefiksi uzaq müştəriyə göndərin

Bir OpenVPN uzaq giriş serverində müştəri marşrutları qoşulma zamanı öyrənir. Push olmadan bölünmüş tunelli müştəri 10.20.0.50-ni öz şlüzünə göndərir və paket heç vaxt tunelə daxil olmur.

push "route 10.20.0.0 255.255.255.0"

Push edilmiş marşrut müştəri qoşulanda qüvvəyə minir, ona görə onlayn qalan istifadəçi yenidən qoşulmayana qədər heç nə görmür. Müştəridə yoxlayın: ip route get 10.20.0.50 Linux-da, route print Windows-da. Çıxış tunel interfeysini adlandırmalıdır.

Push mərkəzə kömək etmir. O, müştəriyə mesajdır, serverdə marşrut deyil və yönləndirmə icazəsi deyil, ona görə mükəmməl push sətri olan mərkəz axını bir hop sonra yenə atır. İnsanların push uğursuz oldu qənaətinə gəlməsinin adi səbəbi budur.

Mərkəzə real çıxış marşrutu verin

Mərkəzin qərargah prefiksi üçün öz növbəti hopu lazımdır. Marşrutlaşdırılmış tuneldə bu, sayt-sayt interfeysindən keçən adi marşrutdur və bir əmr həm seçilmiş marşrutu, həm seçilmiş mənbəyi göstərir:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Sayt-sayt ayağı özü OpenVPN olduqda, marşrut həmin konfiqurasiyada yaşaya bilər və qarşı tərəfin tunel ünvanı şlüz kimi işlədilir: route 10.20.0.0 255.255.255.0 172.30.0.2. Şlüz məcburidir. Onu buraxın və növbəti hop tətbiqin defoltuna düşür, bu da tək-uzaq müştəri ilə çox-qarşılıqlı mərkəz arasında fərqlənir.

Siyasət əsaslı IPsec fərqlidir: mərkəzin nüvəsi paketi adi LAN şlüzünə göndərir və siyasət onu çıxışda tutur, ona görə tunel marşrutu ya heç nə etmir, ya da trafiki siyasətin yanından keçirir. Yuxarıdakı əmrdə mənbəyə baxın, çünki hovuz ünvanı yerinə 10.10.0.1 olması nüvənin uzaq tərəfin rədd edəcəyi ünvanı seçdiyini bildirir. iroute də cavab deyil; o, serverə hansı müştərinin öz tunelinin arxasındakı alt şəbəkəyə sahib olduğunu deyir, üçüncü sayt üçün trafiki hara göndərməyi yox.

Uzaq tərəfi istifadəçi hovuzuna qədər genişləndirin

Qərargah artıq mərkəzin LAN-ını, 10.10.0.0/24, əhatə edir. İstifadəçi hovuzu ikinci prefiksdir və seçicilərdə də olmalıdır, əks halda 10.80.0.25-ə ünvanlanmış cavabı heç bir siyasət əhatə etmir. Hər qarşı tərəf öz tərəfindən eyni prefiks cütlüyünü adlandırır:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Bir cihazın local_ts-i digərinin remote_ts-idir. Mərkəz blokunu qərargaha kopyalayın və cüt tərsinə çevrilir, ona görə child SA heç vaxt qalxmır.

Köhnə ipsec.conf sintaksisi vergüllə ayrılmış leftsubnet istifadə edir. İşləyən təhlükəsizlik assosiasiyası razılaşdırdığı seçiciləri saxlayır, ona görə redaktədən sonra tuneli yenidən qurun. 10:00-da dəyişdirilmiş seçici 09:40-da qalxmış SA-ya qarşı sınanırsa yenə uğursuz olur, halbuki konfiqurasiya faylı boyu düzgün görünür.

Sonra son hopu yoxlayın. ip route get 10.80.0.25 uzaq son nöqtədə tunelə işarə etməlidir. Xidmət defolt şlüz kimi LAN marşrutlaşdırıcısı istifadə edirsə, həmin marşrutlaşdırıcıya da qayıdış marşrutu lazımdır, əks halda cavab orada ölür. tcpdump -ni eth1 host 10.80.0.25 həmin seqmentdə işə salmaq cavabın son nöqtəni ümumiyyətlə tərk edib-etmədiyini göstərir.

Axına mərkəzdə icazə verin

Yönləndirmə aktiv olmalı və yol icazəli olmalıdır. Qaydaları iki prefikslə məhdudlaşdırın, interfeyslər arasında hər şeyi qəbul etmək yerinə.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Ters-yol filtrləmə onun yanındakı səssiz uğursuzluqdur: iki ayaq fərqli interfeyslərdə olduqda, rp_filter=1 cavabı atə bilər, halbuki qəbul qaydasının sayğacı heç tərpənmir. iptables -vnL FORWARD bir cəhddən əvvəl və sonra müqayisə edin. Heç vaxt artmayan qaydaya çatılmır, ona görə onu yenidən yazmaq yerinə bir qat aşağı baxın.

Yalnız bir qrup keçidə ehtiyac duyursa, marşrutu qlobal push-u genişləndirmək yerinə client-config-dir altında müştəri üzrə fayla qoyun. Mərkəzdə mənbə NAT həm də uzaq tərəf qayıdış marşrutuna ehtiyacı aradan qaldırır, amma istifadəçinin ünvanını gizlədir, ona görə uzaq saytın qeydləri və ünvan əsaslı qaydaları istifadəçiləri ayırd etməyi dayandırır.

Müştəridən yoxlayın, sonra tərs qaydada geri qaytarın

Yalnız ICMP deyil, TCP portunu sınayın, çünki ping keçə bilər, xidmət isə bloklu qalır. nc -vz 10.20.0.50 445 və traceroute -n 10.20.0.50 müştəridən ikinci hopun mərkəzin tunel ünvanı olub-olmadığını göstərir. Mərkəzdə, tcpdump -ni tun0 host 10.20.0.50 və eyni filtr sayt-sayt interfeysində: hər ikisində sorğu, heç birində cavab olmaması problemi uzaq tərəfə köçürür.

Sonra bloklu qalmalı olan bir şeyi sınayın. Hovuzun heç vaxt çatmamalı olduğu host da cavab verirsə, keçiddən çoxunu açmısınız və qaydaları daraltmalısınız. Hər şeyi hər qola yönləndirən mərkəz birinci testi keçir, ikincini keçmir.

Geri qaytarma siyahısı saxlayın, çünki dörd obyekt dəyişdi və üçünü unutmaq asandır: push edilmiş marşrut, mərkəzin marşrutu, seçicilər və firewall qaydaları. Onları tərs qaydada ləğv edin, SA-nı yenidən qurun və bir istifadəçi yenidən qoşulsun. Qismən geri qaytarma artıq uyğun gəlməyən tunelə işarə edən marşrut qoyur, bu da ilkin sükutu oxumaqdan çətindir. OpenVPN 2.6 təlimatı sizin versiyanız üçün push, route və iroute sənədləşdirir.