İki mobil sayt, gələn port yoxdur: işləyən hub qurun

Mobil yuxarı kanallar üzərindəki iki sayt hər iki istiqamətdə eyni problemi yaşayır: heç biri sorğusuz IPv4 bağlantısını qəbul edə bilmir, ona görə də heç biri birbaşa tuneldə server rolunu oynaya bilmir. İşləyən arxitektura ortada əlçatan üçüncü tərəf yerləşdirir; hər sayt bayıra zəng edir, orta isə yalnız təsdiqlədiyiniz trafiki ötürür. Bu orta idarə etdiyiniz marşrutlaşdırıcı və ya həmyaşıdları tanış edən məhsul ola bilər və bunlar eyni şey deyil. Aşağıdakı addımlar elə sıralanıb ki, hər biri sübut yaradır, sonra növbəti addım ona əsaslanır.

Heç bir sayta zəng etmək mümkün deyil, ona görə ikisi də bayıra zəng etməlidir

Məhdudiyyəti onun ətrafında dizayn qurmadan əvvəl təsdiqləyin. Əgər operator WAN interfeysinə şəxsi ünvan verirsə, saytın öz marşrutlaşdırıcısındakı heç bir port yönləndirməsi onu əlçatan etməyəcək, çünki tərcümə yuxarı axında baş verir. Eyni kanalda açıq IPv6 ünvanı ola bilər və dizaynı tamamilə dəyişər; buna görə yoxlama hər iki ailəni əhatə edir. Cavabı hər sayt üçün yazın, çünki ikisi eyni operatoru paylaşsa da nadir hallarda eyni məhdudiyyətlərə malikdir.

Adi mobil hal operatorun tərcümə olunmuş aralığından gələn və oradan default marşrut keçən ünvan kimi görünür. Bu düzəldilməli nasazlıq deyil; hub-un mövcud olma səbəbi məhz budur. Axtardığınız şey, sayt ilk danışmadan üçüncü tərəfin çata bildiyi hər hansı ünvandır.

İki əmr qarşısında durduğunuz saytın ünvanlama sualına cavab verir. Onları sayt marşrutlaşdırıcısında işlədin, arxasındakı noutbukda deyil:

ip -4 addr show scope global
ip -6 addr show scope global

Həmyaşıdları kim tanış edir və paketləri kim daşıyır

Tanışlıq və nəql ayrı işlərdir; məhsullar çox vaxt bu sərhədi göstərmədən onları birləşdirir. Görüşmə mexanizmi iki həmyaşıda namizəd yol tapmağa kömək edir; rele isə birbaşa yol olmadıqda onların paketlərini daşıyır. Həmyaşıdları tanış edən xidmət almaq sizə marşrutlaşdırıcı vermir və bu fərq dizaynın ümumiyyətlə hub-a ehtiyacı olub-olmadığını həll edir.

Keçidin öz lüğəti var və sözlər zəmanət deyil, rol təsvir edir. ICE spesifikasiyası namizədləri və bağlantı yoxlamalarını təsvir edir, STUN ünvan tərcüməsini öyrənməyin bir yolunu təsvir edir, TURN isə onu tətbiq edən proqramlar üçün rele ilə nəqli təsvir edir. Bu mexanizmlərin heç biri adi şlüzda görünmür, çünki siz onu kəşf ünvanına yönəltdiniz. Keçidi məhsul imkanı kimi yoxlayın və test əksini göstərənə qədər relenin işlədiyini fərz edin.

Hər sayt üçün bir marşrut, sahibi həmyaşıd

Hub-a hər sayt üçün bir tunel, hər birinin arxasında ayrı LAN prefiksi və hər prefiks üçün sahibini göstərən marşrut lazımdır. Nümunədə hub 10.61.0.1, A saytı LAN 10.60.10.0/24 ilə 10.61.0.11, B saytı isə LAN 10.60.20.0/24 ilə 10.61.0.12-dir. Aşağıdakı hər marşrut tunel interfeysinə deyil, prefiksin sahibi olan həmyaşıda işarə edir:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

Ötürmə aktiv olmalıdır, əks halda paketlər hub-da dayanır və səbəbi göstərən xəta olmur. Son əmr əsl suala cavab verir, çünki mənbə axtarışa daxil edilməklə paketin A saytının LAN-ından B saytının LAN-ına hansı yolu tutacağını soruşur. Tunel interfeysini göstərən axtarışı sübut, default marşruta düşən axtarışı isə sirr deyil, çatışmayan marşrut kimi qəbul edin. Sonra tranziti qəsdən məhdudlaşdırın, çünki hər həmyaşıd arasında ötürmə edən hub iki saytı düz şəbəkəyə çevirir və sahib olduğunuzu düşündüyünüz giriş siyasəti tətbiq olunmaqdan çıxır.

Şifrələmənin harada bitdiyini də qərar verin. Hub hər iki tunel sonluğunu saxladıqda, o maşının operatoru və onun iş yükü etimad və əlçatanlıq modelinə qoşulur, onun buraxılış zolağı yolun bir hissəsi olur.

Hər xəritələməni operator vasitəsilə canlı saxlayın

Hər sayt öz tunelini başladır və hər biri tərcümə xəritələməsini canlı saxlamalıdır, əks halda operator onu unudur. Başladan tərəfdəki canlı saxlama mesajı həmin xəritələməni əl sıxışmaları arasında qoruyur. İcazə verilən prefiksləri hub ünvanı və uzaq LAN ilə məhdudlaşdırın ki, zədələnmiş həmyaşıd sahibi olmadığı prefiksi iddia edə bilməsin:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

Bloku digər saytda öz uzaq prefiksi ilə təkrarlayın və bütün tunel aralığına icazə vermək istəyinə qarşı durun. Dayanıb yeni mənbə portundan davam edən əl sıxışması vaxtı keçmiş xəritələmənin imzasıdır və əl sıxışması vaxt damğaları bunun baş verdiyinin sübutudur. Operatorun fasiləsindən qısa interval vaxtı keçməsinin qarşısını alır, sonradan onu təmir etmir. Operator tərcümə davranışını dəyişdikdə, bu vaxtların da onunla dəyişəcəyini gözləyin.

Hər iki istiqaməti sübut edin, sonra bərpanı sübut edin

Yoxlama istiqamətlidir, ona görə A-dan B-yə ping dizaynın yarısını sübut edir, qayıdış marşrutu haqqında isə heç nə. Cavab yolunu hub-da eyni mənbəni nəzərə alan axtarışla yoxlayın, sonra testi digər tərəfdən təkrarlayın. Təzə əl sıxışmaları da sübuta aiddir, çünki bir saat boş qalmış tunel köhnə xəritələməni sınaqdan keçirə bilər:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

Sonra istədiyiniz uğuru deyil, gözlədiyiniz nasazlığı sınayın. Bir saytın kanalını yenidən başladın və tunelin heç bir ucuna insan toxunmadan qayıtdığını təsdiqləyin, çünki hər operator dəyişikliyindən sonra operator tələb edən dizayn yarımçıqdır. Əsas yolu, mövcud olduqda IPv6 alternativini və hub əlçatmaz olduqda davranışı qeyd edin. Hub artıq əlçatanlıq modelinizin bir hissəsidir, buna görə bunu kəsinti zamanı kəşf etmək əvəzinə yazın.