Du poŝtelefonaj ejoj sen envenantaj pordoj: konstruu nabon kiu funkcias

Du ejoj sur poŝtelefonaj suprenligoj havas la saman problemon en ambaŭ direktoj: neniu povas akcepti nepetitan IPv4-konekton, do neniu povas ludi la servilon en rekta tunelo. La arkitekturo kiu funkcias metas atingeblan trian parton en la mezo: ĉiu ejo registras sin eksteren kaj la mezo plusendas nur la trafikon kiun vi aprobas. Tiu mezo povas esti enkursigilo kiun vi mem funkciigas, aŭ produkto kiu prezentas kunulojn, kaj tio ne estas la sama afero. La paŝoj sube estas ordigitaj tiel ke ĉiu produktas pruvon antaŭ ol la sekva dependas de ĝi.

Neniu ejo estas alvokebla, do ambaŭ devas alvoki eksteren

Konfirmu la limigon antaŭ ol desegni ĉirkaŭ ĝi. Se la portanto donas al la WAN-interfaco privatan adreson, neniu pordplusendo sur la propra enkursigilo de la ejo faros ĝin atingebla, ĉar la traduko okazas pli supre. Publika IPv6-adreso povas ekzisti sur la sama suprenligo kaj tute ŝanĝi la dezajnon, do la kontrolo kovras ambaŭ familiojn. Skribu la respondon por ĉiu ejo, ĉar la du malofte havas identajn limigojn eĉ kiam ili kunhavas portanto.

La ordinara poŝtelefona kazo aspektas kiel adreso el la tradukita gamo de la portanto kun defaŭta vojo tra ĝi. Tio ne estas difekto por ripari; tio estas la kialo ke la nabo ekzistas. Kion vi serĉas estas ajna adreso kiun tria parto povas atingi antaŭ ol la ejo mem parolis.

Du komandoj respondas la demandon pri adresado por la ejo antaŭ kiu vi staras. Rulu ilin sur la enkursigilo de la ejo, ne sur tekokomputilo malantaŭ ĝi:

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

Kiu prezentas kunulojn kaj kiu portas la pakaĵojn

Prestigo kaj transporto estas apartaj taskoj kiujn produktoj ofte faskigas sen igi la limon videbla. Renkontiĝ-mekanismo helpas du kunulojn trovi kandidatan vojon; relao portas iliajn pakaĵojn kiam rekta vojo ne ekzistas. Aĉeti servon kiu prezentas kunulojn ne donas al vi enkursigilon, kaj tiu diferenco decidas ĉu la dezajno entute bezonas nabon.

Travensado havas sian propran vortprovizon, kaj la vortoj priskribas rolojn, ne garantiojn. La ICE-specifiko priskribas kandidatojn kaj konektecajn kontrolojn, STUN priskribas unu manieron lerni pri adres-traduko, kaj TURN priskribas relaean transporton por aplikaĵoj kiuj efektivigas ĝin. Neniu el tiuj mekanismoj aperas en ordinara gateway ĉar vi direktis ĝin al malkovra adreso. Kontrolu travensadon kiel kapablon de la produkto, kaj supozu relaon ĝis testo montros alie.

Unu vojo por ejo, posedata de kunulo

La nabo bezonas unu tunelon por ejo, apartan LAN-prefikson malantaŭ ĉiu kaj vojon por ĉiu prefikso kiu nomas sian posedanton. En la ekzemplo la nabo estas 10.61.0.1, ejo A estas 10.61.0.11 kun LAN 10.60.10.0/24, kaj ejo B estas 10.61.0.12 kun LAN 10.60.20.0/24. Ĉiu vojo sube montras al la kunulo kiu posedas la prefikson, ne al la interfaco de la tunelo:

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

Plusendo devas esti ŝaltita, alie la pakaĵoj haltas ĉe la nabo sen eraro kiu montras la kaŭzon. La lasta komando respondas la veran demandon, ĉar ĝi demandas kiun vojon pakaĵo prenus de la LAN de ejo A al la LAN de ejo B kun la fonto inkludita en la serĉo. Traktu serĉon kiu nomas la interfacon de la tunelo kiel pruvon, kaj unu kiu falas al la defaŭta vojo kiel mankan vojon, ne kiel misteron. Poste limigu la trairejon intence, ĉar nabo kiu plusendas inter ĉiu kunulo transformas du ejojn en ebenan reton kaj la alirpolitiko kiun vi pensis havi ĉesas validi.

Decidu ankaŭ kie la ĉifrado finiĝas. Kiam la nabo tenas ambaŭ tunelfinojn, la funkciiganto de tiu maŝino kaj ĝia laborkvanto aliĝas al la modelo de fido kaj disponeblo, kaj ĝia bendlarĝo iĝas parto de la vojo.

Tenu ĉiun mapadon viva tra la portanto

Ĉiu ejo iniciatas sian propran tunelon, kaj ĉiu devas teni la tradukan mapadon viva, alie la portanto forgesas ĝin. Viva-sava mesaĝo sur la iniciatanta flanko konservas tiun mapadon inter manpremoj. Limigu la permesitajn prefiksojn al la adreso de la nabo kaj la fora LAN, por ke kompromitita kunulo ne povas postuli prefikson kiun ĝi ne posedas:

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

Spegulu la blokon sur la alia ejo kun ĝia propra fora prefikso, kaj rezistu la impulson permesi la tutan tunel-gamon. Manpremo kiu haltas kaj rekomenciĝas de nova fonta pordo estas la signo de eksvalidiĝinta mapado, kaj la tempomarkoj de la manpremo estas la pruvo ke ĝi okazis. Intertempo pli mallonga ol la tempolimo de la portanto malhelpas la eksvalidiĝon anstataŭ ripari ĝin poste. Kiam la portanto ŝanĝas sian tradukan konduton, atendu ke tiuj tempoj ŝanĝiĝos kun ĝi.

Pruvu ambaŭ direktojn, poste pruvu reakiron

Kontrolado estas direkta, do ping de A al B pruvas duonon de la dezajno kaj nenion pri la revena vojo. Kontrolu la respondan vojon per la sama fontkonscia serĉo sur la nabo, poste ripetu la teston de la alia flanko. Freŝaj manpremoj ankaŭ apartenas al la pruvoj, ĉar tunelo senagada dum horo eble testas malnovan mapadon:

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

Poste testu la paneon kiun vi atendas, ne la sukceson kiun vi volas. Restartigu la suprenligon de unu ejo kaj konfirmu ke la tunelo revenas sen ke homo tuŝas ajnan finon, ĉar dezajno kiu bezonas funkciiganton post ĉiu ŝanĝo de la portanto estas nefina. Notu la ĉefan vojon, la IPv6-alternativon kiam ĝi ekzistas, kaj la konduton kiam la nabo ne disponeblas. La nabo nun estas parto de via disponebla modelo, do skribu tion anstataŭ malkovri ĝin dum interrompo.