Bir Pi-də hostapd və OpenVPN: defolt marşrut kimindir?

Telefonlar giriş nöqtəsinə qoşulur, ünvan alır və tunel qalxdıqdan sonra heç bir yerə çatmır. hostapd bu vəziyyətdə adətən sağlamdır, OpenVPN də belədir; pozulan defolt marşrutdur, o ya körpüdə heç vaxt olmayıb, ya da tunel onu VPN serverinin özünə yol qoymadan əvəz edib. Bu sənəd həmin marşrutu öz yerinə qaytarır və nəticəni Pi-dən deyil, klientdən sübut edir. Hər addım geri qaytarıla bilər və burada heç nə tunelin konfiqurasiyasını dəyişmir, ta ki hansı trafiki onun içində istədiyinizi bilənə qədər.

Heç nəyi redaktə etməzdən əvvəl interfeysləri inventarlaşdırın

Adi sxem simsiz radio və kabel portunu br0 içinə yerləşdirir, hostapd-ı körpüyə qarşı başladır və dnsmasq-dan icarələr paylayır, OpenVPN klienti isə tun0 yaradır. Sonra üç ayrı tələb bir kimi görünür: giriş nöqtəsi klientlərinə şlüz kimi Pi lazımdır, Pi-yə serverinə çatmaq üçün internetə marşrut lazımdır və körpüyə həmin klientlərin istifadə edə biləcəyi şlüz ünvanı lazımdır.

Dəyişməzdən əvvəl cari vəziyyəti oxuyun, çünki bu dörd əmr interfeys problemini marşrut problemindən ayırır.

ip -br addr
ip route show
ip link show master br0
bridge link show

Əgər br0 ünvan daşıyır, lakin defolt marşrutu yoxdursa, klientlər Pi-yə çatır, ondan sonra heç nəyə çatmır. Əgər defolt marşrut tunel söndüyü halda tun0-ə işarə edirsə, Pi-nin heç bir işlək yolu olmur və klient simptomu tam eyni görünür. Hər iki hal telefondan eyni görünür, buna görə marşrut cədvəlini birbaşa oxumaq lazımdır.

Körpüyə ona məxsus defolt marşrut verin

Raspberry Pi OS tez-tez körpünü defolt marşrutsuz qoyur, əgər körpü interfeys faylı yazıldıqdan sonra yaranıbsa. Bölmə /etc/dhcpcd.conf faylında olmalıdır və Pi-ni deyil, yuxarı marşrutlaşdırıcını göstərməlidir.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Bu nümunədə 192.168.50.1 mövcud marşrutlaşdırıcıdır və 192.168.50.2 eyni subnetdə Pi-nin körpü ünvanıdır, ona görə rəqəmləri kopyalamaq əvəzinə öz planınızı qoyun. Körpü üzvləri də marşrutlaşdırıcı tələb etməməlidir, əks halda Pi-də qalibi metrik və vaxtdan asılı olan rəqabətli defoltlar yaranır.

systemctl restart dhcpcd əmrindən sonra ip route show default br0-ı bir dəfə göstərməli və kabel portundan dublikat olmamalıdır. Cədvəli deyil, axtarışı təsdiqləyin, çünki köhnə qeyd qalib qeydin yanında otura bilər: ip -4 route get 203.0.113.10 br0-ı göstərməlidir. Bu ünvan TEST-NET-3 sənədləşdirmə diapazonundandır, ona görə bunu oxuyarkən real serverlə toqquşa bilməz.

Tunelin öz serverinə gedən yolu qaçırmasına mane olun

redirect-gateway qəbul edən OpenVPN klienti defolt marşrutu ələ keçirir və onu tunelin içinə yönəldir. Bu, hər giriş nöqtəsi klienti VPN-dən istifadə etməlidirsə doğrudur, yalnız bəzi təyinatlar etməlidirsə yanlışdır. Hər halda, Pi-nin serverlə öz əlaqəsi hələ qurduğu tunelin içində getməməlidir. OpenVPN defoltu yönləndirərkən orijinal şlüzdən uzaq hosta host marşrutu əlavə edir və bu, nəqliyyatı canlı saxlayan davranışdır; bu marşrut yoxdursa, tunel qurulan kimi çökür.

Bu nəqliyyat yolunun qoşulmadan əvvəl və sonra qısa müqayisəsi on saniyəyə dəyər. ip -4 route get 203.0.113.10 hər iki vəziyyətdə alt qat cihazını göstərməlidir, yalnız metrik dəyişir. Əgər tunel qalxdıqdan sonra tun0-i göstərirsə, host marşrutu heç vaxt quraşdırılmayıb və növbəti yenidən qoşulma uğursuz olacaq.

Yalnız seçilmiş prefikslər tuneldən keçməlidirsə, route-nopull istifadə edin və istədiyiniz marşrutları əl ilə əlavə edin və ya serverdən daha dar dəst göndərin. Bu dizaynda körpü defolt marşrutu saxlayır və DNS növbəti qərara çevrilir: dnsmasq-ın ev həlledicisinə yönləndirməsi yalnız orada həqiqətən yaşayan adlar üçün məna kəsb edir.

Yönləndirmə və NAT məsələsini qərarlaşdırın

Tam tunel Pi-də aktiv yönləndirmə və giriş nöqtəsi subnetini marşrutlaşdırmağa hazır uzaq tərəf şlüzü tələb edir. Yönləndirməni hər şeydən əvvəl yoxlayın, çünki sıfır bütün marşrut dəyişikliklərini əhəmiyyətsiz edir.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT qaydası server giriş nöqtəsi prefiksini qəbul etmədikdə işləyən qısa yoldur, bunun qiyməti hər klientin uzaq tərəf jurnallarında Pi-nin tunel ünvanı kimi görünməsidir. Prefiksi NAT olmadan marşrutlaşdırmaq ünvanları görünən saxlayır və ev tərəfində 192.168.50.0/24 üçün geri marşrutdan asılıdır.

Seçimi firewall qaydalarının yanında yazın, çünki dizaynda görünməyən NAT qaydası altı ay sonra izaholunmaz olur. IPv6-nı eyni qərarda saxlayın; işlək IPv4 yolu pozulmuş IPv6 yolunun yanında brauzerdə hələ də yarım pozulmuş kimi oxunur.

Klientdən yoxlayın, sonra təmiz geri qaytarın

Giriş nöqtəsindəki telefondan və ya noutbukdan bu ardıcıllıqla sınayın: dnsmasq-dan icarə, körpü ünvanına ping, sonra tunelin uzaq tərəfində bir təyinat. Hər addım bir təbəqəni təcrid edir, tək bir faydasız uğursuzluq yaratmaq əvəzinə.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Sonra Pi-nin hələ də öz çıxış yolu olduğunu təsdiqləyin: ip route get 203.0.113.10 alt qat cihazını göstərməlidir və server ICMP-yə icazə verirsə ping -c 3 -I br0 203.0.113.10 cavab verməlidir. İlk iki klient addımı keçsə və üçüncüsü uğursuz olsa, nasazlıq yönləndirmə və ya NAT-dadır. İkinci addım uğursuz olsa, körpü və ya DHCP hələ natamamdır.

Geri qaytarma bir fayl redaktəsi və iki əmrdir: bölməni silin, dhcpcd-ni yenidən başladın və defolt marşrutu açıq şəkildə ip route replace default via 192.168.50.1 dev br0 ilə əvəz edin. Bunu texniki xidmət pəncərəsi bağlanmazdan əvvəl edin, sonra deyil, çünki defolt marşrutunu itirmiş Pi onu təmir etmək üçün istifadə edəcəyiniz şəbəkədən əlçatmaz olur.