Ginagamit pa rin ng WireGuard ang lumang endpoint pagkatapos ng mga pagbabago sa DNS

Huminto ang tunel sa pagpasa ng trapiko matapos lumipat ang DNS record ng server, at tama ang pagresolba ng pangalan mula sa parehong makina. Hindi magkasalungat ang dalawang katotohanang ito. May endpoint ang isang WireGuard configuration, at niresolba ng tool ang pangalan sa sandaling ilapat nito ang configuration na iyon, kaya ang tumatakbong interface ay maaaring magpatuloy sa paggamit ng address na nakuha nito ilang oras na ang nakalipas. Tingnan kung ano ang ginagamit ng interface bago ka magpalit ng mga key o sumaling sa saklaw ng tunel.

Isang beses lang nareresolba ang pangalan, hindi tuloy-tuloy

Kinukuha ng pangunahing WireGuard configuration ang endpoint bilang address at port, at niresolba ng tool na nag-aangat ng interface ang hostname sa sandaling iyon. Walang anuman sa pangunahing protocol ang nagtatanong sa DNS ayon sa iskedyul, at ang client application ay maaaring magdagdag ng sarili nitong pag-uugali sa pag-refresh sa ibabaw nito. Ang pagtatala ng naresolbang address, pamilya at port sa tabi ng pangalan ay nagpapakita ng agwat na iyon. Kung wala ang talaang iyon, mukhang tama ang configuration habang kausap ng interface ang ibang lugar.

May isang tunay na awtomatikong update, at sulit itong malaman dahil mukha itong pag-refresh ng DNS ngunit hindi. Maaaring lumipat ang endpoint ng peer kapag dumating ang trapikong wastong na-authenticate mula sa bagong address, na roaming at hindi resolusyon ng pangalan. Sinusundan nito ang peer, kaya hindi nito matutuklasan ang isang walang kaugnayang bagong server na hindi kailanman kinontak ng lumang endpoint.

Ihambing ang record sa address na ginagamit

Itanong ang dokumentadong pangalan sa pamamagitan ng resolver na ginagamit ng client, pagkatapos ay itanong sa interface kung aling endpoint ang hawak nito. Ang dalawang sagot ang paghahambing na nagpapasya sa natitirang bahagi ng pahinang ito:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

Ang mga show subcommand na ginagamit ng mga linyang ito ay nakatala sa manwal ng wg(8). Ihambing din ang pamilya ng address, hindi lang ang address, dahil ang record na nagkaroon ng IPv6 entry ay ibang paghahambing kaysa sa isang nagbago ang IPv4 address. Kung naiiba ang endpoint sa record, tumatakbo ang interface sa lumang impormasyon at ang pangalan ay hindi kailanman naging problema. Kung magkatugma sila at nabigo pa rin ang tunel, pumunta sa listener at mga patakaran sa halip na sa profile.

Nasa bloke iyon ang timestamp ng handshake dahil hindi sinasabi ng endpoint lamang kung maaabot ang peer. Ang lumang timestamp sa tabi ng tamang endpoint ay problema sa landas, hindi sa resolusyon, at binabago ng pagkakaibang iyon ang susunod mong hawakan.

I-restart sa pamamagitan ng tagapamahala ng interface

Kapag nakumpirma na luma na ang endpoint, i-refresh ito sa pamamagitan ng mekanismong nagmamay-ari ng interface sa halip na i-edit ang tumatakbong configuration. Para sa interface na sinimulan ng wg-quick iyon ay pababa at pataas, para sa systemd unit ito ay restart, at para sa interface na pag-aari ng tagapamahala ito ay pagbabagong ginawa sa tagapamahalang iyon, dahil ang pag-edit habang tumatakbo ay napapalitan sa susunod na paglalapat:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Pagkatapos, tiyakin na ang kapalit na listener at ang pagkakakilanlan nito ay ang serbisyong nilayon mo. Ang paglipat ng DNS ay hindi pagbabago ng pagkakakilanlan, kaya hindi ito dapat maging pagkakataon para magtiwala sa key na hindi mo na-verify. Kung nag-uulat na ngayon ang interface ng bagong address at wala pa ring handshake, lumipat na ang sira sa bagong landas ng network o sa listener, na pag-unlad at hindi ang parehong sira nang dalawang beses.

Handshake muna, pagkatapos ang landas ng data

Paghiwalayin ang dalawang kinalabasan bago pumili ng checklist. Ang handshake na nagtatagumpay sa ilalim ng application na nabigo ay problema sa landas ng data: mga ruta, pinapayagang prefix o DNS sa loob ng tunel. Ang handshake na hindi kailanman nangyayari ay problema sa maabot o pagkakakilanlan sa endpoint. Ang pagsasama ng dalawa ay gumagawa ng ulat na walang makapag-uulit at talaan ng pagbabago na may tatlong walang kaugnayang edit.

Itala ang pangalan, ang naresolbang address, ang endpoint na ginagamit at kung natapos ang handshake. Ang apat na katotohanang iyon ay sumasagot sa tanong na paulit-ulit na itinatanong ng sirang ito, at ginagawa ang susunod na pangyayari na pagsusuring dalawang minuto. Nananatiling magkahiwalay na gawain ang pagpapanatili ng pangalan at pag-ampon ng client: ang pagwawasto ng record ay hindi nagsasagawa ng pag-ampon, at ang pag-restart ng interface ay hindi nag-aayos ng record na mali pa rin.