To mobilsider utan innkomande portar: bygg ein hub som fungerer

To sider på mobile uplink har same problem i begge retningar: ingen av dei kan godta ei uoppfordra IPv4-tilkopling, så ingen av dei kan spele serveren i ein direkte tunnel. Arkitekturen som fungerer set ein nåbar tredjepart i midten: kvar side ringjer ut, og midten vidaresender berre trafikken du godkjenner. Denne midten kan vere ein ruter du sjølv driftar, eller eit produkt som presenterer partar, og det er ikkje det same. Trinna nedanfor er ordna slik at kvart trinn gjev prov før det neste er avhengig av det.

Ingen av sidene kan ringjast opp, så begge må ringje ut

Stadfest avgrensinga før du designar rundt henne. Viss operatøren gjev WAN-grensesnittet ei privat adresse, vil inga portvidaresending på sida sin eigen ruter gjere henne nåbar, fordi omsetjinga skjer lenger oppe. Ei offentleg IPv6-adresse kan finnast på same uplink og endre designet fullstendig, derfor dekkjer kontrollen begge familiane. Skriv ned svaret per side, fordi dei to sjeldan har identiske avgrensingar sjølv når dei deler operatør.

Det vanlege mobiltilfellet ser ut som ei adresse frå det omsette området til operatøren med ein standardrute gjennom henne. Det er ikkje ein feil som skal reparerast; det er grunnen til at huben finst. Det du ser etter, er kvar som helst adresse ein tredjepart kan nå utan at sida har snakka først.

To kommandoar svarar på adresseringsspørsmålet for sida du står framfor. Køyr dei på sida sin ruter, ikkje på ein berbar PC bak han:

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

Kven presenterer partar, og kven ber pakkane

Presentasjon og transport er separate oppgåver som produkt ofte slår saman utan å gjere grensa synleg. Ein møtemekanisme hjelper to partar å finne ein kandidatveg; ein relay ber pakkane deira når ingen direkte veg finst. Å kjøpe ein teneste som presenterer partar gjev deg ikkje ein ruter, og den skilnaden avgjer om designet treng ein hub i det heile.

Traversering har sitt eige vokabular, og orda skildrar rollar, ikkje garantiar. ICE-spesifikasjonen skildrar kandidatar og tilkoplingstestar, STUN skildrar ein måte å lære om adresseomsetjing, og TURN skildrar vidaresend transport for applikasjonar som implementerer det. Ingen av desse mekanismane viser seg i ein vanleg gateway fordi du peika han mot ei oppdagingsadresse. Verifiser traversering som ein produkteigenskap, og gå ut frå relay til ein test viser noko anna.

Éin rute per side, eigd av ein part

Huben treng ein tunnel per side, eit eige LAN-prefiks bak kvar og ei rute for kvart prefiks som nemner eigaren. I dømet er huben 10.61.0.1, side A er 10.61.0.11 med LAN 10.60.10.0/24, og side B er 10.61.0.12 med LAN 10.60.20.0/24. Kvar rute nedanfor peikar på parten som eig prefikset, ikkje på tunnelgrensesnittet:

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

Vidaresending må vere aktivert, elles stoppar pakkane ved huben utan ein feil som peikar på årsaka. Den siste kommandoen svarar på det eigentlege spørsmålet, fordi han spør kva veg ein pakke ville ta frå LAN-et til side A til LAN-et til side B med kjelda inkludert i oppslaget. Behandle eit oppslag som nemner tunnelgrensesnittet som prov, og eit som fell tilbake til standardruta som ei manglande rute, ikkje eit mysterium. Avgrense deretter gjennomgangen med vilje, fordi ein hub som vidaresender mellom kvar part gjer to sider til eit flatt nettverk, og tilgangspolicyen du trudde du hadde sluttar å gjelde.

Bestem òg kvar krypteringa sluttar. Når huben held båe tunnelendepunkta, blir operatøren av den maskina og arbeidslasta hennar del av tillits- og tilgjengelegheitsmodellen, og bandbreidda blir del av vegen.

Hald kvar mapping i live gjennom operatøren

Kvar side startar sin eigen tunnel, og kvar må halde omsetjingsmappinga i live, elles gløymer operatøren henne. Ein keepalive på den initierande sida bevarer mappinga mellom handtrykka. Avgrense dei tillatne prefiksa til hubadressa og det eksterne LAN-et, slik at ein kompromittert part ikkje kan krevje eit prefiks han ikkje eig:

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

Spegle blokka på den andre sida med sitt eige eksterne prefiks, og motstå trongen til å tillate heile tunnelområdet. Eit handtrykk som stoppar og held fram frå ein ny kjeldeport er signaturen på ei utløpt mapping, og tidsstempla til handtrykket er provet på at det skjedde. Eit intervall kortare enn tidsavbrotet til operatøren hindrar utløpet i staden for å reparere det etterpå. Når operatøren endrar omsetjingsåtferda si, må du vente at desse tidene endrar seg med han.

Prov begge retningar, prov deretter gjenoppretting

Verifiseringa er retningsbestemt, så ein ping frå A til B provar halve designet og ingenting om returvegen. Kontroller svarvegen med same kjeldebevisste oppslag på huben, og gjer deretter testen om att frå den andre sida. Friske handtrykk høyrer òg til provet, fordi ein tunnel som har stått stille i ein time kanskje testar ei gammal mapping:

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

Test deretter svikten du ventar, ikkje suksessen du ønskjer. Start uplinken til éi side på nytt og stadfest at tunnelen kjem tilbake utan at eit menneske rører nokon av endane, fordi eit design som treng ein operatør etter kvar endring hos operatøren er uferdig. Noter den primære vegen, IPv6-alternativet når det finst, og åtferda når huben ikkje er tilgjengeleg. Huben er no ein del av tilgjengelegheitsmodellen din, så skriv det ned i staden for å oppdage det under eit avbrot.