OpenVPN tuneli ilə IPv6: ev routeri üçün addım-addım bələdçi
Tunel routerin yönləndirə bilmədiyi prefiksi verdikdə IPv6 ölür və ya sızır. Müştəri, hovuz, yönləndirmə, proxy NDP və geri yolunu sıra ilə araşdırın.
Noutbukda IPv6 ünvanı var, tunel IPv4 üzərində işləyir, amma hər IPv6 testi uğursuz olur. Daha pisi: test keçir və trafik heç vaxt tunelə girmədən ISP yolundan çıxıb. Hər iki nəticə eyni çatışmayan qərara dayanır: heç kim routerə müştərilərə doğru yönləndirə biləcəyi prefiks verməyib. Yolu müştəridən bayıra doğru izləmək hansı hissənin çatışmadığını tapır.
Müştərinin oturduğu yerdən başlayın
Serverə toxunmadan əvvəl müştəriyə baxın. ip -6 addr hovuzdan gələn tunel ünvanını, ip -6 route isə tunel cihazına baxan ötürülmüş prefiksi göstərməlidir. Ünvan varsa və marşrut yoxdursa, ötürmə çatmır və ya müştəri onu nəzərə almayıb. Heç biri yoxdursa, server heç nə təyin etməyib.
Sonra müştərinin xarici dünya haqqında nə düşündüyünə baxın. Tunel üzərindən standart marşrut bütün IPv6 trafikini, 2000::/3 üçün marşrut isə yalnız qlobal unicast-ı əhatə edir. Hər ikisi doğru ola bilər və sızma ilə bağlı fərqli suallara cavab verir.
Ümumiyyətlə IPv6 standart marşrutu olmayan müştəri tunelin özü tam sağlam olsa da hər açıq testdə uğursuz olur. Bu, tunelin xətası deyil, siyasətdə boşluqdur.
Serverin həqiqətən yönləndirə bildiyi hovuzu yoxlayın
Server yalnız həqiqətən nəzarət etdiyi prefiksdən ünvan verə bilər. ISP /56 delegasiya edirsə, tunel üçün bir /64 ayırın, qalanını LAN üçün saxlayın. ISP WAN-da yalnız bir /64 verir və əlavə marşrut qurmursa, LAN prefiksinə toxunmayın və tunelə unikal lokal diapazon verin, müştərilərin qlobal çıxışı olmayacağını qəbul edin.
Hovuz və ötürmə birlikdə işləyir. server-ipv6 2001:db8:80:10::/64 ünvanları təyin edir, push "route-ipv6 2000::/3" isə müştərilərə tunelə nə göndərəcəklərini deyir. 2000::/3 ötürməsi qlobal unicast-ı əhatə edir və link-local ilə multicast diapazonlarını tuneldən kənarda saxlayır.
Seçilmiş prefiksi yerləşdirmə qeydinə yazın. Növbəti dəfə ISP ötürməsini dəyişən şəxs tunelin artıq hansı /64-ü tutduğunu bilməlidir.
İkinci ailə üçün yönləndirməni açın
IPv4 yönləndirməsi IPv6 yönləndirməsini avtomatik nəzərdə tutmur. net.ipv6.conf.all.forwarding=1 seçin və IPv4 FORWARD siyasətinin artıq icazə verdiyi hər şeyi təkrarlayın. FORWARD zənciri standart olaraq atan routerdə çatışmayan qaydalar dəsti ölü tunel kimi görünür.
Əl sıxışması keçir, müştəri ünvan alır, geri heç nə gəlmir. Hər iki istiqamət və WAN ayağı üçün qaydalar əlavə edin, çünki LAN-a çatan, amma internetə çatmayan tunel üçüncü testdə uğursuz olur. Uğursuz cəhddən sonra zəncir sayğaclarına baxın, çünki heç vaxt uyğun gəlməyən qayda uyğun gəlib atan qaydadan fərqli problemdir.
ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT
Bir yan təsir sonda tuneli günahlandıranları tutur. Yönləndirməni açanda kernel, başqa cür deməsəniz, Router Advertisement ilə ünvan konfiqurasiyasını ötürür və bu yolla öyrənilən standart marşrut onunla birlikdə yox olur. Ya WAN interfeysinə açıq standart marşrut yazın, ya da orada accept_ra dəyərini qəsdən 2 edin. Hər iki dəyişiklikdən sonra müştəriləri yenidən test etməzdən əvvəl routerin hələ də istifadə oluna bilən IPv6 çıxış yolu olduğunu təsdiqləyin.
Yuxarı tərəf marşrut qurmadıqda qonşu kəşfinə cavab verin
Yuxarı tərəf avadanlığı bəzən delegasiya edilmiş /64-ü öz linkinə aid sayır və hər hansı alt prefiksi VPN qutusuna yönləndirməkdən imtina edir. Bu baş verəndə nəsə hər müştəri ünvanı üçün qonşu sorğularına ayrıca cavab verməlidir.
OpenVPN təyin edilmiş ünvanı client-connect hook-una açır, beləliklə qeydlər əl ilə saxlanan siyahı əvəzinə real hovuzu izləyə bilir. Hook ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 əlavə edir, uyğun client-disconnect hook isə onu silir. Silmə olmadan proxy cədvəli köhnəlir və sonrakı müştəri heç vaxt almadığı ünvan üçün qeydi miras ala bilər. Vəziyyəti ip -6 neigh show proxy ilə təsdiqləyin.
Proxy istifadəsinə müvəqqəti həll kimi baxın. Tunelin /64-ü üçün routerə yönəlmiş statik marşrut müştəri dəyişmələrinə davam gətirir və heç bir imtiyazlı shell hook tələb etmir.
Yolu bayıra doğru, hop-hop izləyin
Bayıra doğru üç addımda test edin: əvvəlcə routerin tunel ünvanı, sonra LAN hostu, üçüncü olaraq traceroute6 ilə açıq hədəf. Hovuzu birinci, yönləndirməni və LAN firewallunu ikinci, yuxarı tərəfə geri yolunu üçüncü sübut edir. Hər uğursuzluq bütün dizaynı yenidən açmaq əvəzinə axtarışı bir cihaza daraldır.
Tunelin MTU-suna baxın, çünki yoldakı IPv6 routerləri sizin üçün fraqmentləməyəcək. Həddindən böyük MTU təmiz uğursuzluq əvəzinə packet-too-big xətası və dayanmış TLS kimi görünür. Onu açıq şəkildə təyin edin və limitə yaxın yüklə test edin.