Twee mobiele locaties zonder inkomende poorten: bouw een hub die werkt

Twee locaties op mobiele uplinks hebben in beide richtingen hetzelfde probleem: geen van beide kan een ongevraagde IPv4-verbinding accepteren, dus geen van beide kan de server spelen in een directe tunnel. De architectuur die werkt zet een bereikbare derde partij in het midden: elke locatie belt naar buiten en het midden stuurt alleen het verkeer door dat je goedkeurt. Dat midden kan een router zijn die je zelf beheert of een product dat peers presenteert, en dat is niet hetzelfde. De stappen hieronder zijn zo geordend dat elke stap bewijs levert voordat de volgende ervan afhangt.

Geen van beide locaties is te bereiken, dus beide moeten naar buiten bellen

Bevestig de beperking voordat je eromheen ontwerpt. Als de provider de WAN-interface een privéadres geeft, maakt geen enkele poortdoorschakeling op de router van de locatie zelf die bereikbaar, omdat de vertaling hogerop gebeurt. Een openbaar IPv6-adres kan op dezelfde uplink bestaan en het ontwerp volledig veranderen, daarom dekt de controle beide families. Noteer het antwoord per locatie, want de twee hebben zelden identieke beperkingen, zelfs niet als ze dezelfde provider delen.

Het gewone mobiele geval ziet eruit als een adres uit het vertaalde bereik van de provider met een standaardroute erdoorheen. Dat is geen defect dat hersteld moet worden; het is de reden dat de hub bestaat. Wat je zoekt is elk adres dat een derde kan bereiken zonder dat de locatie eerst heeft gesproken.

Twee opdrachten beantwoorden de adresseringsvraag voor de locatie waar je voor staat. Voer ze uit op de router van de locatie, niet op een laptop erachter:

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

Wie presenteert peers en wie draagt de pakketten

Presentatie en transport zijn aparte taken die producten vaak bundelen zonder de grens zichtbaar te maken. Een ontmoetingsmechanisme helpt twee peers een kandidaatpad te vinden; een relay draagt hun pakketten als er geen direct pad is. Een dienst kopen die peers presenteert geeft je geen router, en dat verschil bepaalt of het ontwerp überhaupt een hub nodig heeft.

Traversal heeft zijn eigen vocabulaire, en de woorden beschrijven rollen, geen garanties. De ICE-specificatie beschrijft kandidaten en connectiviteitscontroles, STUN beschrijft één manier om over adresvertaling te leren, en TURN beschrijft doorgegeven transport voor toepassingen die het implementeren. Geen van deze mechanismen verschijnt in een gewone gateway omdat je die naar een ontdekkingsadres hebt gericht. Verifieer traversal als producteigenschap, en ga uit van relay tot een test het tegendeel laat zien.

Eén route per locatie, eigendom van een peer

De hub heeft één tunnel per locatie nodig, een apart LAN-prefix achter elk en een route voor elk prefix die de eigenaar noemt. In het voorbeeld is de hub 10.61.0.1, locatie A is 10.61.0.11 met LAN 10.60.10.0/24, en locatie B is 10.61.0.12 met LAN 10.60.20.0/24. Elke route hieronder wijst naar de peer die het prefix bezit, niet naar de tunnelinterface:

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

Doorsturen moet zijn ingeschakeld, anders stoppen de pakketten bij de hub zonder fout die de oorzaak aanwijst. De laatste opdracht beantwoordt de echte vraag, omdat hij vraagt welke weg een pakket zou nemen van het LAN van locatie A naar het LAN van locatie B met de bron in de opzoeking. Behandel een opzoeking die de tunnelinterface noemt als bewijs en een die terugvalt op de standaardroute als een ontbrekende route, niet als een mysterie. Beperk daarna het transitverkeer bewust, want een hub die tussen elke peer doorstuurt maakt van twee locaties een plat netwerk en het toegangsbeleid waarvan je dacht dat je het had, geldt niet meer.

Bepaal ook waar de versleuteling eindigt. Als de hub beide tunneleinden heeft, worden de beheerder van die machine en zijn werklast deel van het vertrouwens- en beschikbaarheidsmodel, en wordt de bandbreedte deel van de route.

Houd elke mapping in leven via de provider

Elke locatie start zijn eigen tunnel, en elk moet de vertaalmapping in leven houden, anders vergeet de provider die. Een keepalive aan de initiërende kant bewaart die mapping tussen de handshakes. Beperk de toegestane prefixen tot het hubadres en het externe LAN, zodat een gecompromitteerde peer geen prefix kan opeisen die niet van hem is:

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

Spiegel het blok op de andere locatie met zijn eigen externe prefix, en weersta de neiging om het hele tunnelbereik toe te staan. Een handshake die stopt en hervat vanaf een nieuwe bronpoort is de signatuur van een verlopen mapping, en de tijdstempels van de handshake zijn het bewijs dat het is gebeurd. Een interval korter dan de time-out van de provider voorkomt het verlopen in plaats van het achteraf te repareren. Als de provider zijn vertaalgedrag wijzigt, verwacht dan dat die tijden meeveranderen.

Bewijs beide richtingen, bewijs daarna het herstel

De verificatie is richtingsgebonden, dus een ping van A naar B bewijst de helft van het ontwerp en niets over de terugweg. Controleer de antwoordroute met dezelfde bronbewuste opzoeking op de hub, en herhaal de test daarna vanaf de andere kant. Verse handshakes horen ook bij het bewijs, want een tunnel die een uur stil lag test misschien een oude mapping:

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

Test daarna de storing die je verwacht, niet het succes dat je wilt. Herstart de uplink van één locatie en bevestig dat de tunnel terugkomt zonder dat een mens een van beide uiteinden aanraakt, want een ontwerp dat na elke wijziging bij de provider een beheerder nodig heeft, is onvoltooid. Leg het primaire pad, het IPv6-alternatief wanneer dat bestaat, en het gedrag vast wanneer de hub niet beschikbaar is. De hub is nu deel van je beschikbaarheidsmodel, dus schrijf dat op in plaats van het tijdens een storing te ontdekken.