Pi-də hotspot müştəriləri TUN VPN üzərindən ev LAN-na çatmır

Yerli Wi-Fi və Ethernet müştəriləri Pi-nin hotspotuna qoşulur, onun DHCP sahəsindən ünvan alır və internet səhifələrini şikayətsiz yükləyir. Sonra həmin müştərilər ev LAN-ındakı fayl paylaşımını və ya veb interfeysi açarkən vaxt aşımına uğrayır, halbuki Pi özü həmin LAN-a tunel üzərindən çatır. Simli olmayan qatda heç nə pozulmayıb. Çatışmayan şey marşrutlaşdırılmış müqavilədir: hotspot prefiksi TUN interfeysinə daşınmalıdır və ev tərəfində nəsə cavabları ora necə göndərəcəyini bilməlidir. Tək bir paketin gediş-dönüşü tamamlaya bilməsi üçün hər iki yarım mövcud olmalıdır.

Üç fərqli işi olan üç qoşma

Linux Ethernet körpüsü kadrları təyinat MAC ünvanına görə ötürür. OpenVPN TUN rejimində IP paketlərini daşıyır və heç bir MAC qatına malik deyil, ona görə yerli körpü əlavə etmək tuneli heç vaxt port kimi qeyd etmir. kernel TUN/TAP sənədləri bu ayrımı izah edir: TAP cihazı Ethernet interfeysinə bənzəyir, TUN cihazı isə yox. İki yerli portu körpüləyib sonra marşrutlaşdıran dizayn, interfeys adları nə deyirsə desin, marşrutlaşdırıcıdır.

Bu fərq sahibliyi həll edir. Müştərilərin subneti, onların standart şlüzü və həmin sahə üçün DHCP səlahiyyəti Pi-nin yerli planına aiddir. Ev DHCP yayımları marşrutlaşdırılmış tuneldən keçmir və heç bir körpü parametri bunu dəyişmir; müştəriləri ev DHCP serverinə yönəltmək öz uğursuzluq rejimləri olan ayrıca, qəsdən edilmiş relay dizaynıdır.

Modemi də müştəri körpüsündən kənarda saxlayın. PPP qoşması fərqli etiketli Ethernet cihazı deyil və pppd-nin sənədləşdirilmiş standart marşrut məntiqi IPCP danışıqlarından sonra işləyir və həmin keçid düşəndə öz marşrutunu geri çəkir. DHCP şablonunu kopyalayıb hər usb0-ı ppp0 ilə əvəz etmək şlüz, metrik və ya həyat dövrü haqqında heç nə sübut etmir.

Hər hansı konfiqurasiyanı redaktə etməzdən əvvəl prefiksləri seçin

Üst-üstə düşən prefikslər firewall qaydalarından daha çox axşam itirir, çünki üst-üstə düşmə tunel sağlam olsa belə marşrut axtarışını səhv interfeysə göndərir. Pi-də artıq mövcud olanı sadalamaqla başlayın, sonra nəticəni dörd ayrı hovuz kimi oxuyun.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Birinci hovuz daşıyıcının modemə verdiyi underlay ünvanıdır; hər müştəriyə baxan plandan kənarda qalmalıdır. İkincisi serverin seçdiyi tunel subnetidir, çox vaxt özünün şəxsi /24-ü. Üçüncüsü hotspot körpüsü, dördüncüsü isə çatmaq istədiyiniz ev prefiksidir. Bu nümunədə hotspot 172.28.90.0/24 alır, körpü 172.28.90.1 üzərindədir, ev xidməti LAN-ı isə 192.168.77.0/24 saxlayır; bu, istehlakçı marşrutlaşdırıcılarının gətirdiyi 192.168.1.0/24 və 10.0.0.0/24 standartlarından və 100.64.0.0/10 daşıyıcı aralığından yan keçir.

Hotspotun DHCP sahəsində şlüz kimi yalnız körpü ünvanını elan edin. Hotspot müştərilərinə heç vaxt şlüz kimi ev ünvanı verməyin; onların həmin seqmentə keçid qatı yolu yoxdur.

Hər istiqaməti ona sahib olan tərəfdə marşrutlaşdırın

Pi-nin tunel vasitəsilə ev prefiksi üçün marşruta ehtiyacı var. Server rejimindəki serverlər adətən bu marşrutu itələyir, ona görə əvvəlcə yönləndirmənin aktiv olduğunu və kernin tun0-dən ev ünvanını həll etdiyini təsdiqləyin.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Əgər ip route get hələ də underlay interfeysini bildirirsə, orada dayanın; yolun sonrakı heç bir hissəsi səhv axtarışı bərpa edə bilməz.

Ev cihazlarının 172.28.90.0/24-a marşrutu yoxdur, ona görə cavabları standart şlüzü izləyir və marşrutlaşdırıcıda ölür. İki dəstəklənən düzəliş var. Ya ev marşrutlaşdırıcısında hotspot prefiksini VPN serverinin LAN ünvanına yönəldən statik marşrut əlavə edin, ya da server özü şlüz olduqda müştəri prefiksini serverin öz marşrut cədvəlində qeydiyyata alın. OpenVPN-in çoxmüştəri rejimində müştəriyə xas qovluq bu əlaqəni daşıyır: müştəri sertifikatının ümumi adı ilə adlandırılmış fayl iroute 172.28.90.0 255.255.255.0 və onu server kernelinə quraşdıran uyğun route sətrini saxlayır. Serverdə təxmin edilən kernel marşrutu serverə hansı müştərinin prefiksə sahib olduğunu söyləməklə eyni ifadə deyil.

Bunun işləməsi üçün ev şəbəkəsinin DHCP xidmətini VPN serverinə köçürməyin. Bütün ev üçün standart şlüzü əvəz etmək bir şəxsi geri marşrutu əlavə etməkdən qat-qat böyük dəyişiklikdir və DNS-i, ünvan rezervlərini və yeni icarəni nəzərə almayan hər cihazı uğursuzluğa sürükləyir.

Yönləndirməni firewall-da təxmin etmədən açın

Yönləndirmənin aktiv olması paketin buraxıldığı anlamına gəlmir. Körpüdən tunelə trafik hələ də filtr qaydalarına dəyir və standart rədd yönləndirmə siyasəti hotspot trafikini atır, Pi-nin öz trafiki isə işləməyə davam edir; bu, yuxarıdakı parçalanmış simptomu tam olaraq yaradır.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0-dən tun0-a qəbul qaydasını və uyğun cavab istiqamətini, həmçinin mənbəni yenidən yaza bilən postrouting qaydasını axtarın. Əgər zəncir siyasəti rədddirsə və heç bir qayda uyğun gəlmirsə, siyasəti qəbula çevirmək əvəzinə dar qəbulları əlavə edin və yenidən sınaqdan keçirin.

Tərcümə tələb deyil, siyasət seçimidir. Ev LAN-na doğru mənbə NAT-ı hər hotspot müştərisini Pi-nin tunel ünvanı kimi göstərir, bu da ev qeydlərində müştəri üzrə aidiyyəti itirir və orijinal mənbəyi gözləyən xidmətləri pozur. NAT-sız marşrutlaşdırma müştəri ünvanlarını görünən saxlayır, lakin yuxarıdakı geri marşrutdan asılıdır. Birini seçin və DNS ilə IPv6-ya eyni cür yanaşın, çünki işləyən IPv4 yolunun yanında pozulmuş IPv6 yolu brauzerdə hələ də yarım-pozuq kimi oxunur.

Gediş-dönüşü yoxlayın, sonra onu qəsdən pozun

Hotspot müştərisindən sınaqdan keçirin, heç vaxt Pi-dən, çünki Pi-nin öz trafiki həm yönləndirmə, həm də geri yolunu yan keçir. Bir müştəri ev xidmətinə çatmağa çalışarkən hər iki interfeysi izləyin.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

İki tutulmanı birlikdə oxuyun. br0 üzərində olub tun0 üzərində heç görünməyən sorğular Pi-nin yönləndirmədiyini və ya marşrutun başqa yerə getdiyini bildirir. tun0 üzərində cavabsız sorğular ev tərəfinin geri marşrutu olmadığını və ya serverin paketi filtrlədiyini bildirir. tun0 üzərində olub br0 üzərində yenidən görünməyən cavablar əks filtr qaydasının çatışmadığını bildirir; burada tunel mükəmməl görünür və müştəri hələ də heç nə görmür.

Sonra yolu qəsdən pozun. Modem bağlantısını aşağı salıb yenidən qaldırın və marşrut və tutma yoxlamalarını təkrar işlədin; tuneldən sağ çıxan, lakin yenidən qoşulmada yoxa çıxan marşrut birdəfəlik əmrdə deyil, bağlantı profilində olmalıdır. Tunelin nəqlinin hələ də underlay-dən keçdiyini, özündən keçmədiyini təsdiqləyin; bu, peer-ə host marşrutu olmadan itələnmiş standart marşrut qəbul edildikdə yaranan klassik döngədür.

Dizaynı yalnız hotspot müştərisi ev adını həll edə, TCP xidməti aça və bir modem yenidənqoşulması boyunca sessiyanı canlı saxlaya bildikdə qəbul edin. Əgər tətbiq həqiqətən ev seqmentində Ethernet səviyyəsində kəşf tələb edirsə, yerli körpünü körpülənmiş adlandırıb yayımın görünməsini gözləmək əvəzinə dəstəklənən Layer 2 dizaynı seçin.