Kiel konstrui WireGuard-teston kun du samtavoloj kiu pruvas unu vojon

WireGuard-testo, kiu portas defaŭltan itineron, LAN-prefikson, DNS kaj fajroŝirmilan escepton, ne povas diri al vi, kiu el ili rompiĝis. Reduktu ĝin al du samtavoloj, unu adresparo kaj unu permesata servo, kaj la paneo ne havas lokon por kaŝiĝi. La enuiga bazo estas la diagnozo. Konstruu ĝin unue; ĝi daŭras dek kvin minutojn kaj ŝparas la posttagmezon, kiun vi alie pasigus divenante.

Tio, kion la bazo pruvas, estas pli mallarĝa ol plej multaj homoj atendas. Ĝi pruvas, ke du identecoj konsentas, ke UDP atingas la aŭskultantan pordon kaj ke unu permesata celo portas peton. Plusendado, NAT, LAN-itineroj kaj DNS estas apartaj funkcioj aldonataj poste, unuope.

Ŝlosiloj, adresoj kaj la ununura finpunkto

Generu ŝlosilparon sur ĉiu sistemo kaj transdonu inter ili nur la publikajn duonojn. wg genkey | tee privatekey | wg pubkey > publickey estas la dokumentita unulinia komando, kaj ĝi lasas la privatan ŝlosilon en dosiero, kiun vi poste povas protekti. Elektu tunelajn adresojn el gamo, kiu aperas en neniu alia agordo, kiun vi posedas, ekzemple 10.99.0.1/24 kaj 10.99.0.2/24. Notu, kiu adreso apartenas al kiu maŝino, ĉar ĉiu posta kontrolo dependas de tiu mapado.

Privataj ŝlosiloj neniam vojaĝas. Se testo bezonas unu kopiitan al la alia flanko, la testo jam misiris. Kiam la du sistemoj sidas malantaŭ NAT, almenaŭ unu bezonas atingeblan UDP-pordon dum la alia portas Endpoint-on montrantan al ĝi, kaj la publika adreso kaj pordo apartenas al viaj notoj, ne al viaj supozoj pri 51820.

Pordplusendado, kiu mapas alian eksteran pordon, funkcias bone, kondiĉe ke la Endpoint kongruas kun ĝi. Miskongruoj ĉi tie produktas silenton anstataŭ erarojn, tial indas kontroli ilin surpapere antaŭ sencimigado sur la drato.

La kampoj, kiuj apartenas al wg, kaj tiuj, kiuj ne

La kernkampoj estas malmultaj: PrivateKey kaj ListenPort sub Interface, PublicKey, AllowedIPs kaj Endpoint sub Peer. Address kaj DNS apartenas al wg-quick, ne al wg mem, kaj tiu distingo mordas en la momento, kiam la sama agordo transiras al alia ilo.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs portas du taskojn samtempe. Ĝi elektas, kiuj celoj iras en la tunelon, kaj ĝi rajtigas la samtavolon uzi tiujn fontadresojn ĉe alveno. Pro tio la spegula enskribo aliflanke devas nomi vian tunelan adreson precize; /32 por malĝusta samtavolo legiĝas kiel enkursiga problemo kaj kondutas kiel rajtiga. La WireGuard rapidkomenco montras la saman formon kun du samtavoloj per la kanona vortigo, se vi volas kompari kampnomojn.

Legi la manpremon anstataŭ la ikonon

Levu la interfacon per tio, kio posedas ĝin, poste legu staton anstataŭ statuslumo. wg show presas la lastan manpremon po samtavolo kune kun bajtaj nombriloj, kaj manpremo en la lastaj minutoj signifas, ke ŝlosiloj, finpunkto kaj UDP-vojo ĉiuj funkcias. Nombrilo, kiu supreniras nur en unu direkto, estas sia propra respondo, kaj ĝi ne estas la sama paneo kiel manpremo, kiu neniam okazas.

La du paneoj implicas malsamajn esplorojn. Tute neniu manpremo montras al ŝlosila miskongruo, malĝusta Endpoint, blokita UDP aŭ fajroŝirmilo, kiu faligas la manpremon mem. Manpremo, kiu sukcesas dum datumoj iras nenie, montras al AllowedIPs, servo, kiu ne aŭskultas sur la tunela adreso, aŭ gastiga fajroŝirmilo, kiu akceptas la pordon por la LAN sed ne por la tunela interfaco. Tiuj estas malsamaj duonoj de la sistemo, kaj la bazo apartigas ilin antaŭ ol vi komencas ŝanĝi regulojn.

Pruvi unu permesatan servon, poste la reverson

Sendu peton al la tunela adreso de la alia samtavolo sur servo, kiu devas respondi, kaj elektu ion pli bonan ol ping. Mankanta ICMP-respondo povas esti gastiga filtrado anstataŭ tunela paneo, do silenta ping pruvas neniun direkton. TCP-konekto al pordo, kiun vi scias malfermita, aŭ peto, kiu redonas datumojn, donas al vi respondon, kiun vi povas interpreti.

Rulu la kontraŭan direkton kiel apartan teston kun propra rezulto, ĉar la du direktoj havas apartajn fajroŝirmilajn kaj AllowedIPs-enskribojn kaj povas malsukcesi sendepende. Se la manpremo funkcias kaj la peto ne, la problemo sidas en la datuma vojo, ne en la tunelo: AllowedIPs, la aŭskultanta servo aŭ gastiga fajroŝirmilo. Riparu tion antaŭ ol aldoni plusendadon, NAT aŭ DNS, ĉar alie vi pasigos la posttagmezon sencimigante funkcion, kiu neniam estis la kulpo.

Konservi la bazon kiel referencon

Konservu la funkciantan topologion kaj la profilfonton en loko, el kiu vi povas restaŭri, kaj tenu ilin ekster ĉiu dosierujo, kiu sinkronas al publika servo. Poste aldonu unu funkcion samtempe, ripetante la originan peton post ĉiu: plusendado, NAT, LAN-itinero kaj nur poste DNS. Ĉiu aldono, kiu rompas la teston, nun estas identigebla, ĉar nenio alia moviĝis.

Bazo, kiu nur faras ikonon verda, diris al vi nenion pri tio, kiu aldono kaŭzis la sekvan paneon. Tenu la unu permesatan vojon funkcianta kiel referencon, kaj ĉiu posta ŝanĝo mezuriĝas kontraŭ ĝi.