Twa mobile sites sûnder yngeande poarten: bou in hub dy't wurket

Twa sites op mobile uplinks hawwe yn beide rjochtingen itselde probleem: gjinien kin in net-frege IPv4-ferbining akseptearje, dus gjinien kin de tsjinner spylje yn in direkte tunnel. De arsjitektuer dy't wurket set in berikbere tredde partij yn 'e midden: elke site skillet nei bûten en de midden stjoert allinnich it ferkear troch dat jo goedkarre. Dy midden kin in router wêze dy't jo sels beheare of in produkt dat peers foarstelt, en dat is net itselde. De stappen hjirûnder binne sa oardere dat elk bewiis leveret foardat de folgjende derfan ôfhinget.

Gjin fan beide sites is te skiljen, dus beide moatte nei bûten skilje

Befêstigje de beheining foardat jo deromhinne ûntwerpe. As de operator de WAN-interface in privee-adres jout, sil gjin poartetrochstjoering op 'e router fan 'e site sels it berikber meitsje, om't de oersetting boppe streamt bart. In iepenbier IPv6-adres kin op deselde uplink bestean en it ûntwerp folslein feroarje, dêrom omfettet de kontrôle beide famyljes. Skriuw it antwurd per site op, om't de twa selden identike beheiningen hawwe sels as se ien operator diele.

It gewoane mobile gefal liket op in adres út it oersetbere berik fan 'e operator mei in standertrûte der trochhinne. Dat is gjin fout om te reparearjen; it is de reden dat de hub bestiet. Wat jo sykje is elk adres dat in tredde partij berikke kin sûnder dat de site earst sprutsen hat.

Twa opdrachten beantwurdzje de adressearjende fraach foar de site dêr't jo foar steane. Fier se út op 'e router fan 'e site, net op in laptop derachter:

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

Wa stelt peers foar, en wa draacht de pakketten

Foarstelling en ferfier binne aparte taken dy't produkten faak bondelje sûnder de line sichtber te meitsjen. In moetsjenmeganisme helpt twa peers in kandidaatpaad te finen; in relay draacht har pakketten as der gjin direkte paad is. It keapjen fan in tsjinst dy't peers foarstelt jout jo gjin router, en dat ferskil beslút oft it ûntwerp überhaupt in hub nedich hat.

Trochgong hat syn eigen wurdskat, en de wurden beskriuwe rollen, net garânsjes. De ICE-spesifikaasje beskriuwt kandidaten en ferbiningkontrôles, STUN beskriuwt ien manier om oer adresoersetting te learen, en TURN beskriuwt relayferfier foar applikaasjes dy't it ymplementearje. Gjin fan dy meganismen ferskynt yn in gewoane gateway, om't jo it nei in ûntdekkingsadres rjochte hawwe. Ferifiearje trochgong as in produktkapasiteit, en nim relay oan oant in test oars lit sjen.

Ien rûte per site, eigendom fan in peer

De hub hat ien tunnel per site nedich, in apart LAN-prefiks efter elk en in rûte foar elk prefiks dy't de eigner neamt. Yn it foarbyld is de hub 10.61.0.1, site A is 10.61.0.11 mei LAN 10.60.10.0/24, en site B is 10.61.0.12 mei LAN 10.60.20.0/24. Elke rûte hjirûnder wiist nei de peer dy't it prefiks besit, net nei 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

Trochstjoering moat ynskeakele wêze, oars stopje de pakketten by de hub sûnder flater dy't de oarsaak oanwiist. De lêste opdracht beantwurdet de echte fraach, om't dy freget hokker paad in pakket nimme soe fan it LAN fan site A nei it LAN fan site B mei de boarne yn 'e syktocht. Behannelje in syktocht dy't de tunnelinterface neamt as bewiis en ien dy't werom falt op 'e standertrûte as in ûntbrekkende rûte, net as in riedsel. Behein dêrnei it trochferkear bewust, om't in hub dy't tusken elke peer trochstjoert twa sites ta in plat netwurk makket en it tagongsbelied dat jo mienden te hawwen net mear jildt.

Beslis ek wêr't de fersifering einiget. As de hub beide tunneleinen hâldt, komme de operator fan dy masine en syn wurklêst by it fertrouwen- en beskikberensmodel, en syn bânbreedte wurdt part fan it paad.

Hâld elke mapping libben troch de operator

Elke site begjint syn eigen tunnel, en elk moat de oersettingsmapping libben hâlde oars ferget de operator it. In keepalive oan 'e inisjearjende kant bewarret dy mapping tusken handshakes. Behein de tastiene prefiksen ta it hubadres en it fiere LAN, sadat in kompromittearre peer gjin prefiks opeaskje kin dat er net besit:

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

Spegelje it blok op 'e oare site mei syn eigen fiere prefiks, en wjerstean de oanstriid om it hiele tunnelberik ta te litten. In handshake dy't stopt en wer begjint fan in nije boarnepoarte is de hantekening fan in ferrûn mapping, en de tiidstimpels fan 'e handshake binne it bewiis dat it barde. In ynterval koarter as de timeout fan 'e operator foarkomt it ferrinnen ynstee fan it dêrnei te reparearjen. As de operator syn oersettingsgedrach feroaret, ferwachtsje dat dy timings dêrmei feroarje.

Bewiis beide rjochtingen, bewiis dan herstel

Ferifikaasje is rjochte, dus in ping fan A nei B bewiist de helte fan it ûntwerp en neat oer de weromrûte. Kontrolearje it antwurdpaad mei deselde boarnebewuste syktocht op 'e hub, en werhelje dan de test fan 'e oare kant. Farske handshakes hearre ek by it bewiis, om't in tunnel dy't in oere stil stien hat miskien in âld mapping testet:

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

Test dan de faling dy't jo ferwachtsje, net it súkses dat jo wolle. Start de uplink fan ien site opnij en befêstigje dat de tunnel weromkomt sûnder dat in minske ien fan beide einen oanrekket, om't in ûntwerp dat nei elke feroaring by de operator in operator nedich hat net ôf is. Skriuw it primêre paad, it IPv6-alternatyf as dat bestiet, en it gedrach as de hub net beskikber is, op. De hub is no part fan jo beskikberensmodel, dus skriuw dat op ynstee fan it by in steuring te ûntdekken.