Két mobil oldal bejövő portok nélkül: építsünk működő központot

Két mobil uplinkre kapcsolt oldal ugyanazzal a problémával néz szembe mindkét irányban: egyik sem tud kéretlen IPv4-kapcsolatot fogadni, ezért egyik sem játszhatja a kiszolgáló szerepét egy közvetlen alagútban. A működő architektúra egy elérhető harmadik felet tesz a közepére: mindkét oldal kifelé tárcsáz, a közép pedig csak az általad jóváhagyott forgalmat továbbítja. Ez a közép lehet az általad üzemeltetett útválasztó vagy egy olyan termék, amely bemutatja a partnereket, és ez a kettő nem ugyanaz. Az alábbi lépések úgy vannak sorrendbe állítva, hogy mindegyik bizonyítékot adjon, mielőtt a következő támaszkodna rá.

Egyik oldal sem hívható be, ezért mindkettőnek kifelé kell hívnia

Erősítse meg a korlátot, mielőtt körülötte tervez. Ha a szolgáltató privát címet ad a WAN-interfésznek, az oldal saját útválasztóján semmilyen porttovábbítás nem teszi elérhetővé, mert a fordítás feljebb történik. Ugyanazon a linken létezhet nyilvános IPv6-cím, és ez teljesen megváltoztathatja a tervet, ezért az ellenőrzés mindkét családot lefedi. Jegyezze fel a választ oldalanként, mert a kettő ritkán rendelkezik azonos korlátokkal akkor sem, ha ugyanazt a szolgáltatót használja.

A szokásos mobil eset úgy néz ki, mint a szolgáltató lefordított tartományából származó cím, amelyen alapértelmezett útvonal halad át. Ez nem javítandó hiba; ez az oka annak, hogy a központ létezik. Azt keresi, hogy van-e olyan cím, amelyet harmadik fél elérhet anélkül, hogy az oldal előbb beszélne.

Két parancs válaszol az előtted álló oldal címzési kérdésére. Futtassa őket az oldal útválasztóján, ne egy mögötte lévő laptopon:

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

Ki mutatja be a partnereket, és ki szállítja a csomagokat

A bemutatás és a szállítás külön feladatok, amelyeket a termékek gyakran úgy vonnak össze, hogy a határvonal nem látszik. Egy találkozási mechanizmus segít két partnernek jelölt útvonalat találni; egy relay szállítja a csomagjaikat, ha nincs közvetlen útvonal. Egy partnereket bemutató szolgáltatás megvásárlása nem ad útválasztót, és ez a különbség dönti el, hogy a tervnek egyáltalán szüksége van-e központra.

Az átjárásnak saját szókincse van, és a szavak szerepeket írnak le, nem garanciákat. Az ICE specifikáció a jelölteket és a kapcsolódás-ellenőrzéseket írja le, a STUN egy módot ír le a címfordítás megismerésére, a TURN pedig a relayen keresztüli szállítást írja le azoknak az alkalmazásoknak, amelyek megvalósítják. E mechanizmusok egyike sem jelenik meg egy hagyományos átjáróban, mert egy felderítési címre irányította. Ellenőrizze az átjárást termékképességként, és feltételezzen relayt, amíg egy teszt az ellenkezőjét nem mutatja.

Egy útvonal oldalanként, amely egy partner tulajdona

A központnak oldalanként egy alagútra, mindegyik mögött külön LAN-előtagra és minden előtaghoz egy útvonalra van szüksége, amely megnevezi a tulajdonosát. A példában a központ 10.61.0.1, az A oldal 10.61.0.11 LAN-nal 10.60.10.0/24, a B oldal pedig 10.61.0.12 LAN-nal 10.60.20.0/24. Az alábbi útvonalak mindegyike arra a partnerre mutat, amely az előtagot birtokolja, nem az alagút interfészére:

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

A továbbítást engedélyezni kell, különben a csomagok megállnak a központban anélkül, hogy bármilyen hiba az okra mutatna. Az utolsó parancs a valódi kérdésre válaszol, mert azt kérdezi, melyik útvonalat venné egy csomag az A oldal LAN-járól a B oldal LAN-jára, a forrást is belefoglalva a keresésbe. Azt a keresést, amely megnevezi az alagút interfészét, tekintse bizonyítéknak, azt pedig, amely visszaesik az alapértelmezett útvonalra, hiányzó útvonalnak, nem rejtélynek. Ezután szándékosan korlátozza a tranzitet, mert az a központ, amely minden partner között továbbít, két oldalt lapos hálózattá tesz, és az általad gondolt hozzáférési szabályzat nem érvényesül tovább.

Azt is döntse el, hol végződik a titkosítás. Ha a központ mindkét alagút-végpontot birtokolja, annak a gépnek az üzemeltetője és munkaterhelése bekerül a bizalmi és rendelkezésre állási modellbe, sávszélessége pedig az útvonal részévé válik.

Tartsa életben az egyes leképezéseket a szolgáltatón keresztül

Minden oldal a saját alagútját indítja, és mindegyiknek életben kell tartania a fordítási leképezést, különben a szolgáltató elfelejti. A kezdeményező oldalon lévő életben tartó üzenet megőrzi ezt a leképezést a kézfogások között. Korlátozza az engedélyezett előtagokat a központ címére és a távoli LAN-ra, hogy egy kompromittált partner ne követelhessen olyan előtagot, amely nem az övé:

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

Tükrözze a blokkot a másik oldalon a saját távoli előtagjával, és álljon ellen a kísértésnek, hogy az egész alagúttartományt engedélyezze. Az a kézfogás, amely megáll és új forrásportról folytatódik, a lejárt leképezés aláírása, a kézfogás időbélyegei pedig annak bizonyítékai, hogy megtörtént. A szolgáltató időkorlátjánál rövidebb intervallum megelőzi a lejáratot, ahelyett hogy utólag javítaná. Amikor a szolgáltató megváltoztatja a fordítási viselkedését, számítson arra, hogy ezek az időzítések vele együtt változnak.

Bizonyítsa mindkét irányt, majd a helyreállást

Az ellenőrzés irányfüggő, ezért az A-ból B-be küldött ping a terv felét bizonyítja, a visszaútról semmit. Ellenőrizze a válasz útvonalát ugyanazzal a forrásérzékeny kereséssel a központon, majd ismételje meg a tesztet a másik oldalról. A friss kézfogások is a bizonyíték részét képezik, mert egy egy órán át tétlen alagút talán régi leképezést tesztel:

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

Utána a várt hibát tesztelje, ne a kívánt sikert. Indítsa újra az egyik oldal uplinkjét, és erősítse meg, hogy az alagút emberi beavatkozás nélkül visszatér mindkét végén, mert az a terv, amelyhez a szolgáltatónál történő minden változás után üzemeltető kell, befejezetlen. Jegyezze fel az elsődleges útvonalat, az IPv6-alternatívát, ha van, és a viselkedést, amikor a központ nem elérhető. A központ most a rendelkezésre állási modellje része, ezért írja le, ahelyett hogy kimaradás közben fedezné fel.