WireGuard-prefikso de gastiganto: kial unu adreso funkcias kaj la ceteraj ne

La tunelo estas aktiva, la manpremo okazas ĉiujn du minutojn, kaj precize unu adreso ĉe la alia flanko respondas. Pingoj al la tunela adreso de la partnero funkcias; nenio malantaŭ ĝi funkcias. Iu legas la interfacan agordon, vidas gastigantan prefikson kaj konkludas, ke la masko estas malĝusta. Larĝigi ĝin al /24 riparas la pingon dum tempo kaj poste rompas ion alian. La prefikso neniam estis la kaŭzo, kaj la mankanta itinero ne estas tiu, kiun la masko regas.

Kion la interfaca prefikso fakte kreas

En Linux, asigni adreson al interfaco kreas konektitan itineron por tiu prefikso. Se vi asignas gastigantan prefikson, la konektita itinero kovras unu adreson. Se vi asignas /24, ĝi kovras 256, kaj ĉiu el ili nun estas konsiderata atingebla sur tiu ligo.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Gastiganta prefikso estas tute normala elekto por punkto-al-punkta tunelo, ĉar estas precize unu partnero ĉe la alia fino. La tria komando estas tiu, kiu respondas la demandon de la uzanto: ĝi diras, kiun interfacon la kerno uzus por tiu celo, kaj ĝi montros nenion utilan se neniu itinero kongruas.

Tio estas la tuta klarigo de la simptomo. Unu adreso respondas ĉar ekzistas konektita itinero por ĝi, aŭ ĉar la permesita listo de la partnero hazarde inkluzivas ĝin. Ĉio alia havas neniun itineron kaj estas forĵetata antaŭ ol WireGuard eĉ implikiĝas. La tunelo restas sana la tutan tempon, kaj tial la mansigno-nombrilo daŭre aspektas trankviliga.

AllowedIPs estas du reguloj sub unu nomo

La permesita listo po partnero de WireGuard faras du taskojn samtempe, kaj la agorda sintakso igas ilin aspekti kiel unu. Enen, ĝi rajtigas, kiujn fontadresojn partnero povas prezenti. Elen, ĝi elektas, al kiu partnero paketo estas sendata, trovante la plej specifan kongruon.

Neniu el la du taskoj estas enkursigado. La kerno ankoraŭ devas decidi, ke paketo apartenas al la tunela interfaco antaŭ ol WireGuard rigardas ĝin, kaj tiu decido venas el la enkursiga tabelo. Partnera ero kun larĝa permesita listo ne instalas itineron per si mem.

Tial agordo povas aspekti kompleta kaj konduti malsimetrie. La kliento sendas al la alia flanko ĉar itinero ekzistas, kaj respondoj neniam alvenas ĉar la permesita listo de la alia flanko ne rajtigas la fonton de la kliento, aŭ ĉar la alia flanko havas neniun revenan vojon. Ambaŭ direktoj estas apartaj decidoj kun apartaj fiaskomanieroj. Skribi, kiun vi testas, estas duono de la diagnozo.

De kie venas la itinero

Se vi uzas wg-quick, la itineroj estas generataj por vi el la permesita listo de ĉiu partnero, krom se vi agordis Table = off kaj mem transprenis la kontrolon. Tio estas la konduto dokumentita de la ilo, kaj ĝi estas la kialo, ke agordo sen eksplicitaj itinero-direktivoj tamen funkcias.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Komparu la permesitan liston kun la itineroj, kiuj efektive ekzistas. Partnero, kiu permesas tutan subreton sed produktis nur gastigantan itineron, signifas, ke la helpilo neniam ruliĝis, aŭ ke vi administras la interfacon rekte per wg kaj ip, kaj tiuokaze nenio generas itinerojn por vi.

Kiam vi administras ĝin permane, la itinero estas unu linio kaj ĝia formo estas eksplicita: la celo tra la interfaco, sen pordego ĉar la ligo estas punkto-al-punkta. Aldoni ĝin ne estas provizora solvo por malbona prefikso; ĝi estas la mankanta duono de dezajno, kiu elektis mem administri enkursigadon.

Pli larĝa prefikso ne aldonas la partneran eron

La tentiga ripario estas ŝanĝi la adreson al /24, por ke la konektita itinero kovru la lokan reton de la servilo. Ŝajne ĝi funkcias, kaj la kialo, ke ĝi ŝajne funkcias, estas ke la konektita itinero nun kongruas, ne ke WireGuard lernis ion novan.

Kion vi ankaŭ faris, estas postuli la tutan intervalon kiel rekte atingebla sur tiu ligo, inkluzive adresojn, kiuj apartenas al aliaj partneroj aŭ al loka reto, kiu fakte troviĝas malantaŭ la servilo. Trafiko al tiuj adresoj nun eniras la tunnelon, kaj ĉu ĝi eliras ĉe la alia flanko dependas de la enkursigado kaj la permesitaj listoj de la servilo mem.

La kripta flanko estas sendependa de tio. WireGuard ankoraŭ bezonas eron en la permesita listo, kiu kovras la celon, por elekti partneron, kaj la alia flanko ankoraŭ bezonas eron, kiu kovras vian fonton, por akcepti ĝin. Pli larĝa interfaca prefikso povas liveri nek unu nek la alian.

Konfirmu ambaŭ direktojn antaŭ ol ŝanĝi ion

Traktu la du finojn aparte kaj skribu, kion diras ĉiu. Ĉe la kliento la itinero kaj la partnera ero; ĉe la servilo la spegula bildo plus ĝia propra revena vojo:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

La kapto estas tio, kio decidas disputojn pri direkto. Se elirantaj paketoj aperas sur la tunela interfaco kaj la servilo registras nenion, la fora fino malakceptas ilin, kutime ĉar via fonto estas ekster ĝia permesita listo. Se tute nenio aperas, la itinero mankas aŭ ĝi montras aliloken.

Poste riparu la plej mallarĝan finon. Ero en la permesita listo ĉe la servila flanko por la adreso de via kliento kaj ero ĉe la klienta flanko por la cela subreto estas la normala formo, kaj ĝi lasas la interfacan prefikson trankvila. Larĝigu la prefikson nur se la adresa plano vere volas komunan subreton sur tiu ligo, kaj faru ĝin kiel planan ŝanĝon anstataŭ kiel sencimigan paŝon.