Twee sellulêre persele, geen inkomende poorte: bou 'n hub wat werk

Twee persele op sellulêre opverbindings het in albei rigtings dieselfde probleem: nie een kan 'n onversoekte IPv4-verbinding aanvaar nie, en dus kan nie een die bediener in 'n direkte tonnel speel nie. Die argitektuur wat werk, plaas 'n bereikbare derde party in die middel, waar elke perseel uitwaarts skakel en die middel net die verkeer deurstuur wat jy goedkeur. Daardie middel kan 'n router wees wat jy self bedryf, of 'n produk wat eweknieë aan mekaar voorstel, en dit is nie dieselfde ding nie. Die stappe hieronder is so gerangskik dat elkeen die bewys lewer voordat die volgende daarvan afhanklik is.

Nie een perseel kan geskakel word nie, so albei moet uitwaarts skakel

Bevestig die beperking voordat jy daarom heen ontwerp. As die operateur die WAN-koppelvlak 'n private adres gee, sal geen poortdeurvoer op die perseel se eie router dit bereikbaar maak nie, want die vertaling gebeur stroomop. 'n Publieke IPv6-adres kan op dieselfde opverbinding bestaan en die ontwerp heeltemal verander, en daarom dek die kontrole albei families. Skryf die antwoord per perseel neer, want die twee het selde identiese beperkings selfs wanneer hulle 'n operateur deel.

Die gewone sellulêre geval lyk soos 'n adres uit die operateur se vertaalde reeks met 'n verstekroete daardeur. Dit is nie 'n fout om te herstel nie; dit is die rede waarom die hub bestaan. Waarna jy soek, is enige adres wat 'n derde party kan bereik sonder dat die perseel eerste gepraat het.

Twee opdragte beantwoord die adresseringsvraag vir die perseel voor wie jy staan. Voer hulle op die perseel se router uit, nie op 'n skootrekenaar agter dit nie:

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

Wie stel eweknieë voor, en wie dra die pakkies

Voorstelling en vervoer is aparte take wat produkte dikwels saambondel sonder om die lyn sigbaar te maak. 'n Ontmoetingsmeganisme help twee eweknieë om 'n kandidaatpad te vind; 'n aflos dra hulle pakkies wanneer geen direkte pad bestaan nie. Om 'n diens te koop wat eweknieë voorstel, gee jou nie 'n router nie, en daardie verskil bepaal of die ontwerp hoegenaamd 'n hub nodig het.

Deurgang het sy eie woordeskat, en die woorde beskryf rolle eerder as waarborge. Die ICE-spesifikasie beskryf kandidate en verbindingskontroles, STUN beskryf een manier om adresvertaling te leer ken, en TURN beskryf aflosvervoer vir toepassings wat dit implementeer. Nie een van daardie meganismes verskyn in 'n gewone gateway omdat jy dit na 'n ontdekkingsadres gewys het nie. Verifieer deurgang as 'n produkvermoë, en neem aflos aan totdat 'n toets anders wys.

Een roete per perseel, deur 'n eweknie besit

Die hub het een tonnel per perseel nodig, 'n afsonderlike LAN-prefiks agter elkeen, en 'n roete vir elke prefiks wat die eienaar daarvan noem. In die voorbeeld is die hub 10.61.0.1, perseel A is 10.61.0.11 met LAN 10.60.10.0/24, en perseel B is 10.61.0.12 met LAN 10.60.20.0/24. Elke roete hieronder wys na die eweknie wat die prefiks besit eerder as na die tonnelkoppelvlak:

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

Deurvoer moet geaktiveer wees, anders stop die pakkies by die hub sonder 'n fout wat na die oorsaak wys. Die laaste opdrag antwoord die werklike vraag, want dit vra watter pad 'n pakkie van perseel A se LAN na perseel B se LAN sou neem met die bron by die opsoek ingesluit. Behandel 'n opsoek wat die tonnelkoppelvlak noem as bewys, en een wat na die verstekroete terugval as 'n ontbrekende roete eerder as 'n raaisel. Beperk dan deurgang doelbewus, want 'n hub wat tussen elke eweknie deurstuur, maak twee persele 'n plat netwerk en die toegangsbeleid wat jy gedink het jy het, hou op geld.

Bepaal ook waar die enkripsie eindig. Wanneer die hub albei tonnelaansluitings hou, sluit die operateur van daardie masjien en sy werklading by die vertroue- en beskikbaarheidsmodel aan, en sy bandwydte word deel van die pad.

Hou elke kartering deur die operateur lewendig

Elke perseel begin sy eie tonnel, en elkeen moet die vertaalkartering lewendig hou, anders vergeet die operateur dit. 'n Lewendhouding aan die beginende kant bewaar daardie kartering tussen handdrukke. Beperk die toegelate prefikse tot die hub-adres en die afgeleë LAN, sodat 'n gekompromitteerde eweknie nie 'n prefiks kan opeis wat hy nie besit nie:

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

Spieël die blok op die ander perseel met sy eie afgeleë prefiks, en weerstaan die drang om die hele tonnelreeks toe te laat. 'n Handdruk wat stop en van 'n nuwe bronpoort hervat, is die kenmerk van 'n vervalde kartering, en die handdruk-tydstempels is die bewys dat dit gebeur het. 'n Interval korter as die operateur se tydsperdatum voorkom die verval eerder as om dit daarna te herstel. Wanneer die operateur sy vertalingsgedrag verander, verwag dat daardie tydreëlings daarmee saam verander.

Bewys albei rigtings, bewys dan herstel

Verifikasie is rigtinggebonde, dus 'n ping van A na B bewys die helfte van die ontwerp en niks oor die terugroete nie. Kontroleer die antwoordpad met dieselfde bronbewuste opsoek op die hub, en herhaal dan die toets van die ander kant. Vars handdrukke hoort ook in die bewys, want 'n tonnel wat 'n uur lank ledig was, toets dalk 'n ou kartering:

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

Toets dan die faling wat jy verwag eerder as die sukses wat jy wil hê. Herbegin een perseel se opverbinding en bevestig dat die tonnel terugkeer sonder dat 'n mens aan enige kant raak, want 'n ontwerp wat ná elke operateurverandering 'n operateur nodig het, is onvoltooi. Teken die primêre pad, die IPv6-alternatief wanneer een bestaan, en die gedrag wanneer die hub onbeskikbaar is, aan. Die hub is nou deel van jou beskikbaarheidsmodel, so skryf dit neer eerder as om dit tydens 'n onderbreking te ontdek.