Dwie lokalizacje komórkowe bez portów przychodzących: zbuduj koncentrator, który działa

Dwie lokalizacje na łączach komórkowych mają ten sam problem w obu kierunkach: żadna nie może przyjąć niechcianego połączenia IPv4, więc żadna nie może pełnić roli serwera w tunelu bezpośrednim. Architektura, która działa, umieszcza pośrodku osiągalną stronę trzecią: każda lokalizacja łączy się na zewnątrz, a środek przekazuje tylko ruch, który zatwierdzisz. Ten środek może być routerem, który sam prowadzisz, albo produktem przedstawiającym peery, i to nie jest to samo. Kroki poniżej są uporządkowane tak, aby każdy dawał dowód, zanim następny będzie od niego zależny.

Do żadnej lokalizacji nie można zadzwonić, więc obie muszą łączyć się na zewnątrz

Potwierdź ograniczenie, zanim zaprojektujesz wokół niego. Jeśli operator przydzieli interfejsowi WAN adres prywatny, żadne przekierowanie portu na routerze samej lokalizacji nie uczyni go osiągalnym, bo translacja odbywa się wyżej. Publiczny adres IPv6 może istnieć na tym samym łączu i całkowicie zmienić projekt, dlatego sprawdzenie obejmuje obie rodziny. Zapisz odpowiedź dla każdej lokalizacji, bo obie rzadko mają identyczne ograniczenia, nawet gdy dzielą operatora.

Zwykły przypadek komórkowy wygląda jak adres z przetłumaczonego zakresu operatora z domyślną trasą przez niego. To nie usterka do naprawienia; to powód, dla którego koncentrator istnieje. Szukasz dowolnego adresu, do którego strona trzecia może dotrzeć, zanim lokalizacja odezwie się pierwsza.

Dwie komendy odpowiadają na pytanie o adresację lokalizacji, przed którą stoisz. Uruchom je na routerze lokalizacji, nie na laptopie za nim:

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

Kto przedstawia peery, a kto niesie pakiety

Przedstawianie i transport to osobne zadania, które produkty często łączą, nie czyniąc granicy widoczną. Mechanizm spotkania pomaga dwóm peerom znaleźć kandydacką ścieżkę; przekaźnik niesie ich pakiety, gdy nie ma ścieżki bezpośredniej. Kupno usługi, która przedstawia peery, nie daje routera, a ta różnica decyduje, czy projekt w ogóle potrzebuje koncentratora.

Trawers ma własne słownictwo, a słowa opisują role, nie gwarancje. Specyfikacja ICE opisuje kandydatów i testy łączności, STUN opisuje jeden sposób poznania translacji adresów, a TURN opisuje transport przekaźnikowy dla aplikacji, które go implementują. Żaden z tych mechanizmów nie pojawia się w zwykłej bramie, bo skierowałeś ją na adres wykrywania. Weryfikuj trawers jako możliwość produktu i zakładaj przekaźnik, dopóki test nie pokaże inaczej.

Jedna trasa na lokalizację, należąca do peera

Koncentrator potrzebuje jednego tunelu na lokalizację, osobnego prefiksu LAN za każdą i trasy dla każdego prefiksu, która nazywa jego właściciela. W przykładzie koncentrator to 10.61.0.1, lokalizacja A to 10.61.0.11 z LAN 10.60.10.0/24, a lokalizacja B to 10.61.0.12 z LAN 10.60.20.0/24. Każda trasa poniżej wskazuje peera, który posiada prefiks, a nie interfejs tunelu:

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

Przekazywanie musi być włączone, inaczej pakiety zatrzymują się na koncentratorze bez błędu wskazującego przyczynę. Ostatnia komenda odpowiada na prawdziwe pytanie, bo pyta, którą drogą pakiet pójdzie z LAN lokalizacji A do LAN lokalizacji B ze źródłem uwzględnionym w wyszukiwaniu. Wyszukiwanie wskazujące interfejs tunelu traktuj jako dowód, a takie, które spada na trasę domyślną, jako brakującą trasę, nie zagadkę. Potem świadomie ogranicz tranzyt, bo koncentrator przekazujący między każdym peerem zmienia dwie lokalizacje w płaską sieć i polityka dostępu, którą sądziłeś, że masz, przestaje obowiązywać.

Zdecyduj też, gdzie kończy się szyfrowanie. Gdy koncentrator trzyma oba końce tunelu, operator tej maszyny i jej obciążenie wchodzą do modelu zaufania i dostępności, a jej przepustowość staje się częścią ścieżki.

Utrzymuj każde mapowanie żywe przez operatora

Każda lokalizacja rozpoczyna własny tunel i każda musi utrzymywać mapowanie translacji żywe, inaczej operator je zapomni. Keepalive po stronie inicjującej zachowuje to mapowanie między uzgodnieniami. Ogranicz dozwolone prefiksy do adresu koncentratora i zdalnego LAN-u, aby przejęty peer nie mógł rościć sobie prefiksu, którego nie posiada:

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

Odbij blok w drugiej lokalizacji z jej własnym zdalnym prefiksem i oprzyj się pokusie zezwolenia na cały zakres tunelu. Uzgodnienie, które się zatrzymuje i wznawia z nowego portu źródłowego, jest podpisem wygasłego mapowania, a znaczniki czasu uzgodnienia są dowodem, że tak się stało. Interwał krótszy niż limit czasu operatora zapobiega wygaśnięciu, zamiast naprawiać je później. Gdy operator zmieni zachowanie translacji, spodziewaj się, że te czasy zmienią się razem z nim.

Udowodnij oba kierunki, potem udowodnij odtwarzanie

Weryfikacja jest kierunkowa, więc ping z A do B dowodzi połowy projektu i niczego o drodze powrotnej. Sprawdź ścieżkę odpowiedzi tym samym wyszukiwaniem świadomym źródła na koncentratorze, a potem powtórz test z drugiej strony. Świeże uzgodnienia też należą do dowodów, bo tunel bezczynny przez godzinę może testować stare mapowanie:

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

Potem testuj awarię, której oczekujesz, a nie sukces, którego chcesz. Zrestartuj łącze jednej lokalizacji i potwierdź, że tunel wraca bez dotykania któregokolwiek końca przez człowieka, bo projekt, który po każdej zmianie u operatora wymaga operatora, jest niedokończony. Zanotuj ścieżkę główną, alternatywę IPv6, gdy istnieje, i zachowanie, gdy koncentrator jest niedostępny. Koncentrator jest teraz częścią twojego modelu dostępności, więc zapisz to, zamiast odkrywać podczas awarii.