To mobilsider uten innkommende porter: bygg en hub som fungerer

To sider på mobile uplink har samme problem i begge retninger: ingen av dem kan godta en uoppfordret IPv4-tilkobling, så ingen av dem kan spille serveren i en direkte tunnel. Arkitekturen som fungerer setter en nåbar tredjepart i midten: hver side ringer ut, og midten videresender bare trafikken du godkjenner. Denne midten kan være en ruter du selv drifter, eller et produkt som presenterer parter, og det er ikke det samme. Trinnene nedenfor er ordnet slik at hvert trinn gir bevis før det neste avhenger av det.

Ingen av sidene kan ringes opp, så begge må ringe ut

Bekreft begrensningen før du designer rundt den. Hvis operatøren gir WAN-grensesnittet en privat adresse, vil ingen portvideresending på sidens egen ruter gjøre den nåbar, fordi oversettelsen skjer lenger oppe. En offentlig IPv6-adresse kan finnes på samme uplink og endre designet fullstendig, derfor dekker kontrollen begge familiene. Skriv ned svaret per side, fordi de to sjelden har identiske begrensninger selv når de deler operatør.

Det vanlige mobilscenarioet ser ut som en adresse fra operatørens oversatte område med en standardrute gjennom den. Det er ikke en feil som skal repareres; det er grunnen til at huben finnes. Det du ser etter, er enhver adresse en tredjepart kan nå uten at siden har snakket først.

To kommandoer svarer på adresseringsspørsmålet for siden du står foran. Kjør dem på sidens ruter, ikke på en bærbar PC bak den:

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

Hvem presenterer parter, og hvem bærer pakkene

Presentasjon og transport er separate oppgaver som produkter ofte slår sammen uten å gjøre grensen synlig. En møtemekanisme hjelper to parter å finne en kandidatvei; en relay bærer pakkene deres når ingen direkte vei finnes. Å kjøpe en tjeneste som presenterer parter gir deg ikke en ruter, og den forskjellen avgjør om designet trenger en hub i det hele tatt.

Traversering har sitt eget vokabular, og ordene beskriver roller, ikke garantier. ICE-spesifikasjonen beskriver kandidater og tilkoblingskontroller, STUN beskriver én måte å lære om adresseoversettelse, og TURN beskriver videresendt transport for applikasjoner som implementerer det. Ingen av disse mekanismene vises i en vanlig gateway fordi du pekte den mot en oppdagelsesadresse. Verifiser traversering som en produktegenskap, og anta relay til en test viser noe annet.

Én rute per side, eid av en part

Huben trenger én tunnel per side, et eget LAN-prefiks bak hver og en rute for hvert prefiks som navngir eieren. I eksemplet 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. Hver rute nedenfor peker på parten som eier prefikset, ikke 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

Videresending må være aktivert, ellers stopper pakkene ved huben uten en feil som peker på årsaken. Den siste kommandoen svarer på det egentlige spørsmålet, fordi den spør hvilken vei en pakke ville ta fra side A sitt LAN til side B sitt LAN med kilden inkludert i oppslaget. Behandle et oppslag som navngir tunnelgrensesnittet som bevis, og et som faller tilbake til standardruten som en manglende rute, ikke et mysterium. Begrens deretter gjennomgangen bevisst, fordi en hub som videresender mellom hver part gjør to sider til et flatt nettverk, og tilgangspolicyen du trodde du hadde slutter å gjelde.

Bestem også hvor krypteringen slutter. Når huben holder begge tunnelendepunktene, blir operatøren av den maskinen og arbeidslasten dens en del av tillits- og tilgjengelighetsmodellen, og båndbredden blir en del av veien.

Hold hver mapping i live gjennom operatøren

Hver side starter sin egen tunnel, og hver må holde oversettelsesmappingen i live, ellers glemmer operatøren den. En keepalive på den initierende siden bevarer mappingen mellom håndtrykkene. Begrens de tillatte prefiksene til hubens adresse og det eksterne LAN-et, slik at en kompromittert part ikke kan kreve et prefiks den ikke eier:

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

Speil blokken på den andre siden med sitt eget eksterne prefiks, og motstå trangen til å tillate hele tunnelområdet. Et håndtrykk som stopper og gjenopptas fra en ny kildeport er signaturen på en utløpt mapping, og håndtrykkets tidsstempler er beviset på at det skjedde. Et intervall kortere enn operatørens tidsavbrudd forhindrer utløpet i stedet for å reparere det etterpå. Når operatøren endrer oversettelsesatferden sin, må du forvente at disse tidene endrer seg med den.

Bevis begge retninger, deretter bevis gjenoppretting

Verifiseringen er retningsbestemt, så en ping fra A til B beviser halve designet og ingenting om returveien. Kontroller svarveien med samme kildebevisste oppslag på huben, og gjenta deretter testen fra den andre siden. Ferske håndtrykk hører også til beviset, fordi en tunnel som har stått stille i en time kanskje tester en gammel mapping:

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

Test deretter svikten du forventer, ikke suksessen du ønsker. Start uplinken til én side på nytt og bekreft at tunnelen kommer tilbake uten at et menneske rører noen av endene, fordi et design som trenger en operatør etter hver endring hos operatøren er uferdig. Noter den primære veien, IPv6-alternativet når det finnes, og atferden når huben ikke er tilgjengelig. Huben er nå en del av tilgjengelighetsmodellen din, så skriv det ned i stedet for å oppdage det under et avbrudd.