To mobile steder uden indgående porte: byg et knudepunkt, der virker

To steder på mobile uplinks har samme problem i begge retninger: ingen af dem kan acceptere en uopfordret IPv4-forbindelse, så ingen af dem kan spille serveren i en direkte tunnel. Arkitekturen, der virker, sætter en tilgængelig tredjepart i midten, hvor hvert sted ringer udad, og midten videresender kun den trafik, du godkender. Denne midte kan være en router, du selv driver, eller et produkt, der præsenterer peers, og de to er ikke det samme. Trinene nedenfor er ordnet sådan, at hvert trin giver bevis, før det næste afhænger af det.

Ingen af stederne kan ringes op, så begge må ringe ud

Bekræft begrænsningen, før du designer dig uden om den. Hvis operatøren giver WAN-grænsefladen en privat adresse, vil ingen portvideresendelse på stedets egen router gøre den tilgængelig, fordi oversættelsen sker længere oppe. En offentlig IPv6-adresse kan findes på samme uplink og ændre designet helt, og derfor dækker kontrollen begge familier. Skriv svaret ned pr. sted, fordi de to sjældent har identiske begrænsninger, selv når de deler operatør.

Den almindelige mobile sag ser ud som en adresse fra operatørens oversatte interval med en standardrute gennem den. Det er ikke en fejl, der skal repareres; det er grunden til, at knudepunktet findes. Det, du leder efter, er enhver adresse, som en tredjepart kan nå, uden at stedet har talt først.

To kommandoer besvarer adresseringsspørgsmålet for det sted, du står foran. Kør dem på stedets router, ikke på en bærbar bagved:

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

Hvem præsenterer peers, og hvem bærer pakkerne

Præsentation og transport er adskilte opgaver, som produkter ofte slår sammen uden at gøre grænsen synlig. En mødemekanisme hjælper to peers med at finde en kandidatvej; et relay bærer deres pakker, når der ikke findes en direkte vej. At købe en tjeneste, der præsenterer peers, giver dig ikke en router, og den forskel afgør, om designet overhovedet har brug for et knudepunkt.

Traversering har sit eget ordforråd, og ordene beskriver roller frem for garantier. ICE-specifikationen beskriver kandidater og forbindelseskontroller, STUN beskriver én måde at lære om adresseoversættelse, og TURN beskriver videresendt transport for applikationer, der implementerer det. Ingen af disse mekanismer optræder i en almindelig gateway, fordi du pegede den mod en fundadresse. Verificér traversering som en produktevne, og antag relay, indtil en test viser andet.

Én rute pr. sted, ejet af en peer

Knudepunktet har brug for én tunnel pr. sted, et særskilt LAN-prefiks bag hver og en rute for hvert prefiks, der navngiver dens ejer. I eksemplet er knudepunktet 10.61.0.1, sted A er 10.61.0.11 med LAN 10.60.10.0/24, og sted B er 10.61.0.12 med LAN 10.60.20.0/24. Hver rute nedenfor peger på den peer, der ejer prefikset, i stedet for på tunnelens grænseflade:

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

Videresendelse skal være aktiveret, ellers stopper pakkerne ved knudepunktet uden en fejl, der peger på årsagen. Den sidste kommando besvarer det egentlige spørgsmål, fordi den spørger, hvilken vej en pakke ville tage fra sted A's LAN til sted B's LAN med kilden inkluderet i opslaget. Behandl et opslag, der navngiver tunnelens grænseflade, som bevis, og et, der falder tilbage til standardruten, som en manglende rute frem for et mysterium. Begræns derefter transit bevidst, fordi et knudepunkt, der videresender mellem hver peer, gør to steder til et fladt netværk, og den adgangspolitik, du troede, du havde, holder op med at gælde.

Beslut også, hvor krypteringen slutter. Når knudepunktet holder begge tunnelendepunkter, indgår operatøren af den maskine og dens arbejdsbyrde i tillids- og tilgængelighedsmodellen, og dens båndbredde bliver en del af vejen.

Hold hver mapping i live gennem operatøren

Hvert sted tager initiativ til sin egen tunnel, og hver skal holde oversættelsesmappingen i live, ellers glemmer operatøren den. En keepalive på den initierende side bevarer den mapping mellem håndtrykkene. Begræns de tilladte prefikser til knudepunktets adresse og det eksterne LAN, så en kompromitteret peer ikke kan kræve et prefiks, den ikke ejer:

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

Spejl blokken på det andet sted med dets eget eksterne prefiks, og modstå trangen til at tillade hele tunnelintervallet. Et håndtryk, der stopper og genoptages fra en ny kildeport, er signaturen på en udløbet mapping, og håndtrykkets tidsstempler er beviset for, at det skete. Et interval kortere end operatørens timeout forhindrer udløbet i stedet for at reparere det bagefter. Når operatøren ændrer sin oversættelsesadfærd, forvent, at disse timing ændrer sig med den.

Bevis begge retninger, bevis derefter genopretning

Verifikation er retningsbestemt, så en ping fra A til B beviser halvdelen af designet og intet om returvejen. Kontrollér svarvejen med det samme kildebevidste opslag på knudepunktet, og gentag derefter testen fra den anden side. Friske håndtryk hører også til beviset, fordi en tunnel, der har stået stille en time, måske tester en gammel mapping:

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

Test derefter det svigt, du forventer, i stedet for den succes, du ønsker. Genstart et steds uplink, og bekræft, at tunnelen vender tilbage, uden at et menneske rører nogen af enderne, fordi et design, der kræver en operatør efter hver ændring hos operatøren, er ufærdigt. Notér den primære vej, IPv6-alternativet, når det findes, og adfærden, når knudepunktet er utilgængeligt. Knudepunktet er nu en del af din tilgængelighedsmodel, så skriv det ned i stedet for at opdage det under en afbrydelse.