IPv6 çıxışı OpenVPN yenidən başladıqdan sonra sıradan çıxır: prefiks sahibliyini yoxlayın
Tunel yenidən yaradıldıqdan sonra IPv6 sıradan çıxır. Hər hansı bir şeyi yenidən başlatmazdan əvvəl deleqasiya olunmuş prefiksin, müştəri ünvanlarının və qayıdış marşrutunun kimə aid olduğunu müəyyən edin.
IPv6, OpenVPN yenidən başladığı anda trafiki ötürməyi dayandırır, IPv4 isə işləməyə davam edir. Tunel interfeysi yenidən yaradıldı və onun IPv6 vəziyyətini idarə edən başqa bir şey ya ünvanı, ya da prefeksi əlçatan edən marşrutu itirdi. Üç ayrı vəziyyət hissəsi iştirak edir və hər birinin fərqli sahibi var: provayderin deleqasiya etdiyi prefiks və onun ömrü, VPN müştərilərinə verilən ünvanlar və həmin müştəri prefiksini serverə geri göndərən yuxarı axın marşrutu. Hər hansı daemon-a toxunmazdan əvvəl hər birinin sahibini müəyyən edin, çünki səhv olanı yenidən başlatmaq problemi bir günlük gizlədir və növbəti qoşulmada geri qaytarır.
IPv6 vəziyyətinin üç hissəsi, üç sahibi
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Tunelin içində qlobal əhatəli ünvan tək başına kifayət deyil. Yuxarı axın marşrutlaşdırıcıları həmin prefiksi yenə də VPN serverinə doğru göndərməlidir və onlar bunu serverin təsadüfən oradan bir ünvan tutmasına görə etməyəcəklər.
Buna görə də açıq /64 prefiksini tunel hovuzuna köçürmək risklidir. Serverə marşrutlanan prefiks, yuxarı axının on-link hesab etdiyi prefikslə eyni deyil və qonşu kəşfi bu boşluğu doldurmayacaq.
Heç nəyi dəyişməzdən əvvəl serverin vəziyyətini oxuyun
Vəziyyəti iki dəfə qeyd edin: bir dəfə IPv6 işləyərkən, bir dəfə də yenidən başlatmadan sonra, sonra müqayisə edin. Yalnız oxuma üçün görünüşlər kifayətdir və texniki xidmət pəncərəsi zamanı heç bir şeyə başa gəlmir:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingÜç konkret fərq axtarın: yoxa çıxan marşrut, köhnəlmiş və ya etibarsız ömrə keçmiş ünvan və yenidən deleqasiyadan sonra dəyişən, lakin VPN konfiqurasiyasının hələ də köhnəsini reklam etdiyi prefiks.
Ünvan yox oldusa, amma prefiks dəyişməyibsə, onu təyin edən daemon interfeysi idarə etməyi dayandırıb. Prefiks dəyişdisə, amma ünvanlar dəyişməyibsə, müştəri konfiqurasiyası köhnəlib. İki nasazlıq brauzerdən eyni görünür və heç bir ortaqlığı yoxdur.
dhcpcd tuneli idarə etməlidirmi, qərar verin
dhcpcd interfeysləri kəşf edə və DHCPv6 prefiksinin hissələrini aşağı axın interfeyslərinə deleqasiya edə bilər, konfiqurasiyası isə deleqasiya hədəflərini açıq şəkildə göstərə bilər. Açıq hədəf olmadıqda, sənədləşdirilmiş davranışı digər interfeysləri əhatə edə bilər və tunelin heç kimin planlamadığı bir ünvanla qalması belə olur.
İki şərt sizi tunelin statik ünvanlaşdırmasını OpenVPN-ə verməyə yönəltməlidir: server konfiqurasiyasında sabit ünvanlar göndərir və tunel adı yenidən qoşulmada dəyişir. Hər ikisi doğrudursa, tuneli deleqasiya daemonundan qəsdən kənarlaşdırın və niyə olduğunu izah edən şərh əlavə edin.
Əgər tunelə deleqasiya qəsdən edilirsə, prefiks dəyişikliyinin idarə edilməsini tətbiq edin. Bu, deleqasiya olunmuş prefiks və ya onun ömrü dəyişdikdə reaksiya göstərmək, serverin reklam etdiyi müştəri prefiksini yeniləmək və marşrutu yenidən əlavə etmək deməkdir. Həmin dizaynda interfeysi kənarlaşdırmaq yeni prefiksi bilən yeganə komponenti çıxarır.
dhcpcd-ni yenidən başlatmaq vəziyyəti yenidən yaratdığı üçün nəyisə düzəldirmiş kimi görünə bilər, amma o, həm də fikirləşmədiyiniz interfeyslər üçün konfiqurasiyanı yeniləyir və ya geri götürür. Bu bərpa onu hər VPN yenidən başlatmasından sonra tələb etmir. O, həm də sübut kimi istifadə etdiyiniz sayğacları sıfırlayır. Həqiqətən dəyişdirdiyiniz interfeysin məqsədli yenidən yüklənməsini üstün tutun.
IPv6-nı IPv4 NAT-dan ayrı yoxlayın
Yönləndirmənin aktiv olduğunu və yuxarı axın marşrutunun faktiki müştəri prefiksinə yönəldiyini təsdiqləyin, sonra yeni icazəli IPv6 bağlantısı qurun. Müştərinin öz IPv6 marşrut cədvəlini də yoxlayın, çünki açıq ünvan göstərən müştəri sorğusunun tuneldən istifadə etdiyini sübut etmir.
IPv4 maskalanması fərqli bir problemi həll edir: şəxsi mənbələr üçün qayıdış yolu. Geri götürülmüş IPv6 prefiksi üçün heç nə etmir və onu əlavə etmək IPv6-nı geri qaytarmayacaq.
Sahiblik qeydi ilə bitirin: hansı komponent prefiksi deleqasiya edir, hansı müştəri ünvanlarını təyin edir, hansı qayıdış marşrutunu saxlayır və yenidən qoşulmada hər birinə nə olur. Runbook-dakı dörd sətir növbəti şəxsi vacib olanı tapmaq üçün üç daemon-u yenidən başlatmaqdan xilas edir.