Två mobilsiter utan inkommande portar: bygg en hubb som fungerar

Två siter på mobila uplänkar har samma problem i båda riktningarna: ingen av dem kan acceptera en oombedd IPv4-anslutning, så ingen av dem kan spela servern i en direkt tunnel. Arkitekturen som fungerar sätter en nåbar tredje part i mitten: varje site ringer ut och mitten vidarebefordrar bara trafiken du godkänner. Den mitten kan vara en router du själv driftar eller en produkt som presenterar parter, och det är inte samma sak. Stegen nedan är ordnade så att varje steg ger bevis innan nästa beror på det.

Ingen av siterna kan ringas upp, så båda måste ringa ut

Bekräfta begränsningen innan du designar runt den. Om operatören ger WAN-gränssnittet en privat adress gör ingen portvidarebefordran på sitens egen router den nåbar, eftersom översättningen sker längre upp. En offentlig IPv6-adress kan finnas på samma uplänk och ändra designen helt, därför täcker kontrollen båda familjerna. Skriv ner svaret per site, eftersom de två sällan har identiska begränsningar även när de delar operatör.

Det vanliga mobilfallet ser ut som en adress från operatörens översatta intervall med en standardväg genom den. Det är inte ett fel som ska repareras; det är anledningen till att hubben finns. Det du letar efter är varje adress som en tredje part kan nå utan att siten har talat först.

Två kommandon svarar på adresseringsfrågan för siten du står framför. Kör dem på sitens router, inte på en bärbar dator bakom den:

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

Vem presenterar parter och vem bär paketen

Presentation och transport är separata uppgifter som produkter ofta slår ihop utan att göra gränsen synlig. En mötesmekanism hjälper två parter att hitta en kandidatväg; en relay bär deras paket när ingen direkt väg finns. Att köpa en tjänst som presenterar parter ger dig ingen router, och den skillnaden avgör om designen behöver en hubb alls.

Traversering har sitt eget ordförråd, och orden beskriver roller, inte garantier. ICE-specifikationen beskriver kandidater och anslutningskontroller, STUN beskriver ett sätt att lära sig om adressöversättning, och TURN beskriver vidarebefordrad transport för applikationer som implementerar det. Ingen av dessa mekanismer syns i en vanlig gateway eftersom du pekade den mot en upptäcktsadress. Verifiera traversering som en produktegenskap och anta relay tills ett test visar något annat.

En väg per site, ägd av en part

Hubben behöver en tunnel per site, ett eget LAN-prefix bakom varje och en väg för varje prefix som namnger ägaren. I exemplet är hubben 10.61.0.1, site A är 10.61.0.11 med LAN 10.60.10.0/24, och site B är 10.61.0.12 med LAN 10.60.20.0/24. Varje väg nedan pekar på parten som äger prefixet, inte på tunnelgränssnittet:

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

Vidarebefordran måste vara aktiverad, annars stannar paketen vid hubben utan ett fel som pekar på orsaken. Det sista kommandot svarar på den verkliga frågan, eftersom det frågar vilken väg ett paket skulle ta från site A:s LAN till site B:s LAN med källan inkluderad i sökningen. Behandla en sökning som namnger tunnelgränssnittet som bevis och en som faller tillbaka på standardvägen som en saknad väg, inte ett mysterium. Begränsa sedan genomfarten medvetet, eftersom en hubb som vidarebefordrar mellan varje part gör två siter till ett platt nätverk och den åtkomstpolicy du trodde du hade slutar gälla.

Bestäm också var krypteringen slutar. När hubben håller båda tunneländarna blir operatören av den maskinen och dess arbetsbelastning en del av tillits- och tillgänglighetsmodellen, och dess bandbredd blir en del av vägen.

Håll varje mappning levande genom operatören

Varje site startar sin egen tunnel, och var och en måste hålla översättningsmappningen levande, annars glömmer operatören den. En keepalive på den initierande sidan bevarar mappningen mellan handskakningarna. Begränsa de tillåtna prefixen till hubbens adress och det avlägsna LAN:et, så att en komprometterad part inte kan kräva ett prefix som den inte äger:

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

Spegla blocket på den andra siten med dess eget avlägsna prefix, och motstå frestelsen att tillåta hela tunnelområdet. En handskakning som stannar och återupptas från en ny källport är signaturen på en utgången mappning, och handskakningens tidsstämplar är beviset för att det hände. Ett intervall kortare än operatörens tidsgräns förhindrar utgången i stället för att reparera den efteråt. När operatören ändrar sitt översättningsbeteende, förvänta dig att dessa tider ändras med det.

Bevisa båda riktningarna, bevisa sedan återhämtningen

Verifieringen är riktningsberoende, så en ping från A till B bevisar halva designen och ingenting om returvägen. Kontrollera svarsvägen med samma källmedvetna sökning på hubben, och upprepa sedan testet från andra sidan. Färska handskakningar hör också till beviset, eftersom en tunnel som stått stilla en timme kanske testar en gammal mappning:

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

Testa sedan felet du förväntar dig, inte framgången du vill ha. Starta om en sites uplänk och bekräfta att tunneln kommer tillbaka utan att en människa rör någon av ändarna, eftersom en design som behöver en operatör efter varje ändring hos operatören är oavslutad. Anteckna den primära vägen, IPv6-alternativet när det finns, och beteendet när hubben inte är tillgänglig. Hubben är nu en del av din tillgänglighetsmodell, så skriv ner det i stället för att upptäcka det under ett avbrott.