Du peer listigas areojn, kiuj tuŝas unu la alian, kaj la trafiko atingas la malĝustan. Nenio estas difektita: WireGuard elektas peer per kunigo de la celo kun la agorditaj areoj, kaj la plej specifa kongruo gajnas. Antaŭ ol vi larĝigos ion, decidu, kiu peer posedu kiun prefikson.

La plej longa prefikso gajnas ene de WireGuard

Ĉiu peer-enskribo portas aron de celprefiksoj. Kiam paketo estas enkursigita en la interfacon, la efektivigo serĉas la enskribon kun la plej specifa kongrua prefikso — la sama regulo, kiun aplikas enkursiga tabelo. Do /24 venkas /16, kiu enhavas ĝin, kaj la pli mallarĝa peer ricevas la trafikon.

Road-warrior-agordoj uzas tion intence. Unu peer posedas larĝan areon por ejo, kaj unuopaj gastigantoj estas eltranĉitaj per /32-enskriboj, kiuj apartenas al aliaj peer. La ŝablono funkcias ĉar la eltranĉoj estas pli specifaj, ne pro la ordo.

Skribu la posedrajton kiel tabelon de prefikso kaj peer. Se du enskriboj priskribas la saman prefikson, la agordo jam ne esprimas intencon, ĝi esprimas konkursegon.

La operaciumo elektas unue la interfacon

WireGuard elektas nur inter la peer sur unu interfaco. Kiun interfacon ricevas la paketo decidiĝas pli frue, per la enkursiga tabelo de la gastiganto, kaj dua implicita itinero aŭ malnova itinero povas sendi la trafikon tie, kie la peer-listo neniam vidas ĝin. Tial diagnozo je peer-nivelo povas esti ĝusta kaj tamen ne klarigi la malsukceson. Kontrolu la itineron al la celo antaŭ ol legi la peer-agordon, ĉar itinero montranta al la fizika interfaco preterpasas la tutan demandon.

La ilo kutime instalas tiujn itinerojn el la peer-areoj, kio signifas, ke ŝanĝo en la listo de unu peer povas silente alidirekti trafikon, kiu antaŭe apartenis al alia. Redakto de peer do estas itinera ŝanĝo en masko. Reviziu ambaŭ samtempe, alie vi ripares unu kaj rompos la alian.

Envenantaj paketoj kontroliĝas laŭ fonto

La area listo faras duoblan taskon. Por eliranta trafiko ĝi elektas peer laŭ celo, kaj por envenanta trafiko ĝi rajtigas font-adreson. Paketo alvenanta el adreso ekster la areoj de tiu peer estas forĵetita antaŭ ol iu ajn fajroŝirmilo vidas ĝin.

Tiu malsimetrio facile mankas, kiam vi legas unu flankon de la agordo. Peer, kiu povas atingi subreton, per tio ne rajtas sendi el tiu subreto, kaj la du direktoj estas devigataj de malsamaj kontroloj.

Mallarĝa font-posedrajto igas tion avantaĝo. Donu al ĉiu peer /32 por sia propra adreso, kaj la fajroŝirmilo malsupre havas fidindan fonton por kongruigi, anstataŭ tutgrupan areon, kiun iu ajn membro povus pretendi.

Duoblaj areoj ne estas failover

Asigni la saman prefikson al du peer ne kreas ŝarĝbalancilon nek rezervan vojon. Ne estas san-kontrolo nek seanco-simpatio: la venka enskribo estas decidita de la interna ordo de la efektivigo, kio ne estas kontrakto, laŭ kiu vi devus projektadi. Se vi bezonas alternativajn elirojn, esprimu ilin tie, kie la elekto estas difinita. Enkursiga politiko, metriko aŭ paro da apartaj prefiksoj kun dokumentita posedanto por ĉiu produktas konduton, kiun vi povas antaŭdiri kaj testi.

Larĝigi areon por ripari ne rilatan malsukceson estas la alia ofta eraro. Ĝi forprenas trafikon de la peer, kiu funkciis, kaj la nova simptomo alvenas antaŭ ol la malnova estas komprenita.

Kontrolu la elekton antaŭ redakto

Tri komandoj respondas la tri demandojn laŭorde. La unua listigas la areojn, kiujn ĉiu peer pretendas. La dua montras, kiun interfacon la gastiganto uzus por celo. La tria montras la vivan peer-staton post kiam trafiko fluis.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Rulu ilin antaŭ kaj post ŝanĝo kaj komparu. Se la itinera eligo ŝanĝiĝis sed la trafiko ankoraŭ alvenas ĉe la malĝusta peer, la prefikso-listoj supermetiĝas tiel, kiel vi ankoraŭ ne skribis. Se la itinera eligo ne ŝanĝiĝis, la peer-agordo neniam estis tio, kio estis konsultita.

Notu la celon, la elektitan interfacon kaj la elektitan peer en la bileto. Ĝuste tiu triopo igas supermeton reviziebla poste, kaj ĝi estas multe pli utila ol ekrankopio de la agordo.

Rilataj artikoloj