Artıq IPv4 üzərindən qoşulan və serverin arxasındakı şəxsi IPv4 iş yükünə çatan müştəriniz var. Məqsəd xarici nəqliyyata toxunmadan həmin tuneldən şəxsi IPv6 iş yükünə çatmaqdır. Bu sıra vacibdir: xarici yol IPv4 olaraq qalır və yalnız daxili ünvan planı, müştəri marşrutu və serverdən LAN-a qayıdış yolu dəyişir. Beş yoxlama nöqtəsi, hər birində davam etməzdən əvvəl baxılacaq konkret bir şey.

Yoxlama nöqtəsi bir: artıq işləyən bağlantı

Hər hansı şey əlavə etməzdən əvvəl müştərini qoşun və IPv4 yolunu təsdiqləyin. İşlək tunel sizə yeni IPv6 səhvini köhnə bağlantı problemindən ayıran baza xətti verir. Həm də hansı server nüsxəsini həqiqətən redaktə etdiyinizi göstərir.

Havuzu, topologiyanı və artıq etibar etdiyiniz itələnmiş marşrutları qeyd edin. IPv6 işi o konfiqurasiyanı genişləndirir; onu əvəz etmir.

Yoxlama nöqtəsi iki: daxili prefiksləri seçin

Sayt üçün ULA /48 seçin və ondan iki /64 ayırın: biri tunel müştəriləri, biri IPv6 iş yükünü saxlayan LAN seqmenti üçün. Nümunə prefiksi kopyalamaq əvəzinə 40 bitlik qlobal ID yaradın və hər iki alt şəbəkəni saytın artıq marşrutlaşdırdığı bütün şəbəkələrlə yoxlayın:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

İki müstəqil /64 müştəri havuzunun LAN seqmentindən kəsilməsinin qarşısını alır; bu, qayıdış marşrutunu yazarkən vacib olur. Yuxarıdakı dəyərlər bir işlənmiş nümunədir, təkrar istifadə ediləcək prefiks deyil.

Yoxlama nöqtəsi üç: köməkçini və marşrut itələməsini əlavə edin

Hər hansı şey əlavə etməzdən əvvəl mövcud server konfiqurasiyasını oxuyun. Mövcud direktivin ikinci nüsxəsi birincisi ilə birləşmir və yaranan xəta IPv6 deyil, direktivin adını çəkir. Mövcud IPv4 köməkçisi yerindəykən iki sətir onu genişləndirir. Hər biri fərqli suala cavab verir:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Birincisi interfeysi və müştəri havuzunu konfiqurasiya edən rahat köməkçidir. İkincisi müştərinin çatmalı olduğu LAN təyinatını göstərir. Müştəriyə IPv6 ünvanı vermək serverin arxasında hansı şəbəkələrin olduğunu demir, ona görə hər iki sətir lazımdır.

Köməkçi statik IPv6 havuzu ilə və ya nopool ilə birgə mövcud olmur. Əgər yerləşdirmə ünvanları qəsdən statik ayırırsa, bu siyasəti saxlayın və nümunəyə uyğunlaşdırmaq üçün siyasəti silmək əvəzinə IPv6 ekvivalentini açıq şəkildə dizayn edin.

Yoxlama nöqtəsi dörd: yönləndirmə və cavab marşrutu

Serverdə IPv6 yönləndirməsini sistemin öz konfiqurasiya sahibi vasitəsilə yandırın, unudacağınız birdəfəlik runtime yazısı ilə deyil. Runtime forması sürətli test üçün faydalıdır. Daimi konfiqurasiya distributivin şəbəkə sahibinin oxuduğu drop-in faylına aiddir:

sysctl -w net.ipv6.conf.all.forwarding=1

Yönləndirmə paketləri marşrutlaşdırmaqdan əlavə hostun IPv6 davranışını dəyişir. Müştəri kimi Router Advertisement qəbul edən host yönləndirməyə başlayanda eyni şəkildə bunu dayandırır. Buna görə IPv6 uplinkı RA-lardan asılı olan maşın həmin uplink üçün açıq plana ehtiyac duyur.

Sonra LAN-a tunel hovuzuna qayıdan marşrut verin. İş yükünün IPv6 şlüzü VPN serveri deyil, LAN marşrutlaşdırıcısıdır, ona görə marşrut həmin marşrutlaşdırıcıda olub serverin LAN ünvanına yönəlir:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Linkin ehtiyac duyduğu ICMPv6 növlərini, o cümlədən yol-MTU əks əlaqəsini saxlayın. IPv4 firewall qaydası IPv6 qaydası demək deyil və hər şeyi bloklayan IPv6 qadağası qonşu kəşfini marşrut xətası kimi görünən şəkildə pozur.

Yoxlama nöqtəsi beş: müştərini oxuyun, sonra test edin

Müştərini yenidən qoşun və serverin köməkçi ünvanından çıxarmaq əvəzinə həqiqətən aldığı ünvanları oxuyun. İnterfeys siyahısı hər iki ailəni eyni cihazda göstərir:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Tuneli seçən marşrut müştərinin paketi hara göndərəcəyini bildiyini sübut edir. Serverin onu yönləndirdiyini, LAN marşrutlaşdırıcısının qayıdış marşrutuna sahib olduğunu və ya tətbiqin cavab verməyə icazəli olduğunu sübut etmir.

Tətbiqin özünü hər ailə üzərində növbə ilə test edin, sonra yenidən qoşulmadan və host yenidən başladıqdan sonra təkrarlayın. Yalnız yenidən başlamaya qədər qalan marşrut və ya sysctl testdir, dizayn deyil.

AAAA qeydini yalnız IPv6 yolu başdan-başa cavab verdikdən sonra dərc edin. IPv4 üzərindən sorğulanan DNS hələ də IPv6 ünvanı qaytara bilər, ona görə həll olunan ad heç nəyin dinlədiyinin sübutu deyil. RFC 4193 ULA təlimatı bu prefiksləri kopya deyil, sizin edən qlobal ID-nin yaradılmasını əhatə edir.

Əlaqəli məqalələr