WireGuard: walang ruta sa peer pagkatapos ng pagbabago ng subnet — dalawang labasan

Sariwa ang handshake sa wg show, tama ang endpoint, hindi kailanman nagbago ang mga key — at sinasabi pa rin ng ping na walang ruta sa peer. Binago mo ang subnet ng tunnel isang oras na ang nakalipas. Ang sintomas na iyon ay ang lagda ng hindi pagkakatugma ng prefix at hindi ng problema sa key: natapos ng WireGuard ang handshake at pagkatapos ay itinapon ang data dahil hindi na tugma ang source address sa tatanggapin ng peer na tumatanggap. May dalawang makatuwirang paraan para maisagawa ang pagbabago ng subnet, at nabibigo sila sa magkaibang lugar.

Dalawang paraan para maisagawa ang pagbabago, at ang halaga ng bawat isa

Ang opsyon A ay muling pagbilang sa lugar: i-edit ang address ng interface, ang mga saklaw ng peer, ang mga ruta at bawat kopya ng configuration, pagkatapos ay i-reload. Ang opsyon B ay magtayo ng pangalawang interface sa bagong prefix sa tabi ng luma, ilipat ang mga peer, at alisin ang lumang interface kapag talagang lumipat na ang trapiko.

Ang kalahating naisagawa na estado ang nagpapadelikado sa opsyon A, dahil hindi ito mukhang sira. Bumabangon ang interface, nagtatagumpay ang handshake, at ang landas ng data lamang ang nabibigo. Mas maraming trabaho ang opsyon B ngunit pinananatiling buhay ang gumaganang landas habang hinahanap mo ang bawat sanggunian.

Ano ang dapat gumalaw nang sabay sa iyong panig

Apat na bagay sa lokal na host ang naglalarawan ng parehong subnet, at ang pagbabago sa isa ay pagbabago sa lahat: ang address ng interface, ang AllowedIPs ng bawat peer, ang rutang ginagamit ng system para sa mga destinasyong iyon, at anumang ini-install ng manager sa iyong ngalan. Sa wg-quick, ang huling dalawa ay nalilikha mula sa configuration sa tuwing bumabangon ang interface, kaya tahimik na muling ini-install ng lumang kopya ang lumang prefix.

Ihambing ang naka-configure sa aktwal na tumatakbo sa halip na magtiwala sa alinman sa dalawa:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

Ang paghahanap ng ruta ang hakbang na nilalaktawan ng mga tao. Sinasagot nito kung ano talaga ang gagawin ng kernel para sa isang destinasyon, kabilang ang mas partikular na rutang iniwan ng manager o runtime ng container. Kung nag-uulat ito ng ibang interface kaysa sa tunnel, hindi ang configuration ang problema.

Para sa tumatakbong interface, ilapat ang na-edit na file nang hindi ginigiba ang tunnel:

wg syncconf wg0 <(wg-quick strip wg0)

Ina-update nito ang mga peer at saklaw sa lugar. Hindi nito ina-update ang address ng interface o ang mga ruta, dahil hindi iyon mga setting ng WireGuard — kaya ang muling pagbilang ay nangangailangan pa rin ng muling paglikha ng interface o pagbabago ng address gamit ang ip, at pagkatapos ay muling pagsuri ng routing.

Ano ang dapat gumalaw nang sabay sa malayong dulo

Dito karaniwang namamatay ang pagbabago ng subnet. Ang AllowedIPs ay hindi lamang pahiwatig ng routing; ito rin ang listahan ng mga source address na maaaring ipakita ng isang peer. Kapag muling binilang mo ang mga kliyente at hinayaan ang AllowedIPs ng server sa lumang prefix, tinatanggap ng server ang handshake, natatanggap ang naka-encrypt na mga packet at itinatapon ang mga ito dahil ang panloob na source ay hindi tugma sa anumang saklaw na iniuugnay nito sa peer na iyon. Walang error na naitatala, at nakikita ng kliyente ang timeout.

Kaya i-update ang panig na tumatanggap nang may layunin: dapat ilista ng entry ng peer sa server ang bagong prefix ng kliyente, dapat ituro ng sariling pabalik na ruta ng server ang tunnel para sa prefix na iyon, at dapat matutunan ng anumang downstream network sa likod ng server ang bagong landas. Kailangan din ng parehong pagtrato ang patakaran ng firewall na nagpangalan sa lumang saklaw, at gayundin ang anumang gumagawa ng pagpili batay sa source.

Mura ang diagnostic na naghihiwalay sa dalawang pagkabigo. Ang sariwang handshake na walang data ay nangangahulugang buhay ang tunnel at hindi nagkakasundo ang panloob na addressing. Walang handshake sa lahat ay nangangahulugang tinitingnan mo ang maabot o ang mga key. Huwag paikutin ang mga key dahil sa problema sa prefix; nire-reset nito ang tanging bagay na gumagana.

Mga lumang kopya na nabubuhay nang mas matagal kaysa sa iyong edit

Ang pag-edit ng file ay hindi katulad ng pagbabago ng tumatakbong system, at mas marami ang mga kopya kaysa inaasahan ng mga tao: ang unit o manager na nagmamay-ari ng interface, pangalawang profile na may parehong pangalan sa ibang direktoryo, container na ang configuration ay niluto sa isang image, interface ng router na may sariling na-edit na bersyon, at client app na muling nag-import ng naka-save na tunnel sa paglunsad. Alinman sa mga ito ay maaaring magbalik ng lumang prefix pagkatapos na mukhang kumpleto ang iyong pagbabago.

Naglalakbay din ang mga pangalan. Kung gumagana ang numeric na ruta ngunit nabibigo ang hostname, may panloob na DNS record o configuration ng serbisyo na nakaturo pa rin sa lumang address ng tunnel. Ayusin ang sanggunian sa halip na palawakin ang bawat saklaw ng peer, na magtatakip sa tunay na problema at sabay na magpapalaki sa ACL ng source.

Panatilihing bukas ang isang landas ng pagbawi habang nagtatrabaho: pangalawang paraan ng pagpasok sa host, serial console, o naka-iskedyul na rollback ng mga configuration file. Ang pagbabago ng tunnel na nagla-lock sa iyo palabas ng makina na binabago mo ang pinakakaraniwang paraan na nagiging isang gabi ang gawaing ito.

Pagpili sa pagitan ng dalawa, at pag-verify ng pagputol

Piliin ang A kapag pagmamay-ari mo ang bawat peer, maliit ang bilang, at katanggap-tanggap ang maikling pagkawala. Piliin ang B kapag ang mga peer ay malalayong kamay na hindi mo kontrolado, kapag dapat manatiling buhay ang link sa pagitan ng mga site, o kapag hindi mo magagarantiya na maa-update ang bawat kopya sa isang pass. Sa ganoong kaso idagdag ang bagong prefix sa parehong interface, ilipat ang mga peer nang isa-isa, panoorin ang trapiko sa bago, at pagkatapos lamang alisin ang lumang interface at ang mga ruta nito.

Sa alinmang opsyon, tapos na ang pagbabago kapag pumasa ang apat na pagsusuri: sariwa ang handshake, pinapangalanan ng paghahanap ng ruta para sa destinasyon sa bagong prefix ang tunnel, dumadaan ang payload na ilang daang byte sa dalawang direksyon, at ganoon din pagkatapos ng restart ng host o ng manager. Para dito, ang manwal ng wg(8) ang sanggunian para sa kung ano ang ibig sabihin ng AllowedIPs sa bawat direksyon, at sulit itong basahin muli bago mo palawakin ang isang saklaw para mawala ang isang sintomas.

• Sariwang handshake at walang data: tingnan ang AllowedIPs sa tumatanggap bago hawakan ang mga key.
• Nakaturo ang paghahanap ng ruta sa maling interface: pagmamay-ari ng manager o container ang ruta, hindi ang iyong file.
• Maayos ang numeric na address at sira ang hostname: lumang sanggunian, hindi routing loop.
• Kumpleto lamang ang pagbabago kapag pagkatapos ng restart ay ginagamit pa rin ang bagong prefix.