OpenVPN üzərindən ictimai prefiks: qayıdış yolunu düzəldin

Tunelin qalxmasını və müştərinin qarşı tərəfi ping etməsini izləyin, sonra VPN-in arxasında olan ictimai ünvan başqa yerdən cavab verir, ya da heç cavab vermir. Bu simptomun adətən şifrə və ya sertifikatlarla heç bir əlaqəsi yoxdur. Provayderin marşrutlaşdırdığı prefiks IP marşrutu kimi çatdırılır və onu OpenVPN üzərindən daşımaq həmin marşrutu iki səviyyədə təkrar yaratmaq və qayıdış yolunda mənbə ünvanını qorumaq deməkdir. WAN-ı körpüləmək tələb olunmur və ünvanı interfeysə əlavə etmək yuxarı marşrutu yaratmır.

Prefiks əvvəlcə sizə marşrutlanmalıdır

Provayderdən blokun necə çatdırıldığını soruşun. Serverinizin əsas ünvanına marşrutlanan prefiks, provayderin WAN seqmentində birbaşa gözlədiyi ünvanlardan fərqli bir şeydir. Buradakı dizaynla yalnız birinci model işləyir.

Provayder 198.51.100.64/28-i giriş serverinizə marşrutlaşdırırsa, bu aralıq üçün paketlər serverə gəlir və siz onları yönləndirməsəniz orada dayanır. Provayder əvəzində aralığı yuxarı xəttinizə körpüləyirsə, server onun üçün ARP cavabı verməlidir, bu isə başqa problemdir.

OpenVPN-ə toxunmazdan əvvəl çatdırılma modelini sınayın: kənardan blokdakı bir ünvana ping göndərin və onu hansı interfeysin qəbul etdiyinə baxın. Heç nə gəlmirsə, heç bir tunel konfiqurasiyası kömək etməyəcək. Ünvan WAN-da birbaşa cavab verirsə, provayder marşrutlamaq əvəzinə körpüləyir və aşağıdakı dizayn tətbiq olunmur.

İki marşrutlaşdırma səviyyəsi: nüvə marşrutu və iroute

OpenVPN prefiksi iki yerdə lazımdır. Nüvə prefiksin tunel cihazına aid olduğunu bilməlidir ki, yönləndirilən paketlər standart marşrut əvəzinə OpenVPN-ə daxil olsun. OpenVPN həm də hansı autentifikasiya olunmuş müştərinin prefiksə sahib olduğunu bilməlidir və bu, müştəriyə xas qovluqdakı iroute girişidir.

Server tərəfindəki marşrut belə görünür, prefiks və maska ayrılmaya uyğun olmalıdır:

ip route add 198.51.100.64/28 dev tun0

Müştəriyə xas konfiqurasiya sahibliyi təyin edir. Onu müştəri sertifikatının ümumi adı ilə adlandırılmış CCD faylına qoyun və həmin qovluğun serverin həqiqətən oxuduğu qovluq olduğunu təsdiqləyin:

iroute 198.51.100.64 255.255.255.240

OpenVPN-in marşrutlanmış şəbəkələr sənədi hər iki səviyyəni və nə üçün ayrı olduqlarını izah edir. iroute olmadan nüvə marşrutu paketləri sahibsiz tunelə göndərir və OpenVPN onları atır. Nüvə marşrutu olmadan iroute paketləri serverin standart yolunda qoyur. Hər iki səhv müştəri tərəfindən pozulmuş tunel kimi görünür.

Xidmət ünvanı harada yaşayır

Delegasiya edilmiş prefiks tunelin öz ünvanları ilə eyni şey deyil. İstəsəniz keçidi özəl fəzadan nömrələyin və ictimai xidmət ünvanını xidmətin həqiqətən işlədiyi yerə qoyun.

Xidməti yerli olaraq sonlandıran Linux müştərisində tək bir host ünvanı kifayətdir:

ip address add 198.51.100.70/32 dev lo

Prefiks daha sonra VM hostuna və ya başqa LAN-a marşrutlanırsa, əvəzində həmin aşağı axın yolunu və onun qayıdış marşrutunu konfiqurasiya edin. Blokdakı hər ünvanı VPN müştərisinə təyin etmək tələb olunmur və sonralar ziddiyyətlər yaradır.

Qayıdış yolunda ictimai mənbəni saxlayın

Delegasiya edilmiş prefiksdən cavab tuneldən çıxmalı və provayderin marşrutuna çatmalıdır. Uzaq host onu öz ISP-si ilə göndərirsə, mənbə ünvanı saxta görünür və provayder ya da təyinat onu atır. Düzəliş mənbəyə əsaslanan qayda və ya xüsusi marşrutlaşdırma cədvəlidir, daha geniş NAT deyil. O olmadan xidmət tunel qonşusundan işləyir və hər başqa yerdən uğursuz olur.

Giriş serverində geniş masquerade qaydası adi günahkardır. O, ictimai mənbəni serverin əsas ünvanına yenidən yazır və müştəri həqiqi ünvanı heç vaxt görmür:

iptables -t nat -S POSTROUTING

NAT-ı ona ehtiyacı olan özəl VPN müştəriləri ilə məhdudlaşdırın və delegasiya edilmiş prefiksi tərcüməsiz buraxın. Sonra serverin prefiksi ümumiyyətlə yönləndirdiyini təsdiqləyin, çünki standart olaraq rədd edən yönləndirmə zənciri onu səssizcə atır.

Etibar etməzdən əvvəl hər iki istiqaməti yoxlayın

Yoxlama bir deyil, dörd müşahidədir. Provayder marşrutunun gəldiyini, nüvənin prefiksi tunelə göndərdiyini, OpenVPN-in onu düzgün müştəriyə aid etdiyini və cavabın ictimai mənbə salamat qayıtdığını təsdiqləyin. Hər müşahidənin öz əmri var, buna görə uğursuzluq bütün dizaynı deyil, bir qatı göstərir. Hər konfiqurasiya dəyişikliyindən sonra onları bu ardıcıllıqla işə salın.

Nüvədən delegasiya edilmiş ünvanın hansı yolu tutduğunu soruşun və sorğu gedərkən tuneli izləyin:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Əks yol filtrləmə düzgün marşrutu ləğv edə bilər. Tuneldə və yuxarı xəttdə effektiv parametri yoxlayın və yadda saxlayın ki, sərt rejim mənbəyi gəldiyi interfeysə uyğun olmayan trafiki rədd edir:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Nəhayət, uğursuzluq halını sınayın. Tuneli dayandırın və ictimai prefiksin adi yuxarı xəttdən sızmadığını təsdiqləyin. VPN-in bərpası xidməti hostun açdığı portları genişləndirmədən geri gətirməlidir.