Bumabagsak ba ang VPN pagkatapos ng DHCP renewal? Ihambing ang mga address

Ang renewal ng lease at pagkabigo ng VPN ay madalas magkasamang lumitaw sa mga log kaya napagpasyahan ng mga tao na ang isa ay nagdudulot ng isa. Totoong may pagkakataon sa oras; ang sanhi ay karaniwang wala. Ang renewal ay isang unicast na kahilingan sa server na naglabas ng lease, na ipagpatuloy ang parehong binding, at maaaring palawigin ito ng server nang hindi binabago ng kliyente ang kahit isang address. Ang pagsusuri sa sariling mga halaga ng kliyente sa paligid ng pangyayari ay naghihiwalay ng tahimik na na-renew na lease mula sa network na tunay na nagbago sa ilalim ng tumatakbong tunnel.

Magsimula sa kliyenteng bumagsak

Buksan muna ang log ng koneksyon ng kliyente at itala ang oras ng pagbagsak hanggang sa segundo. Pagkatapos buksan ang log ng network ng operating system para sa parehong minuto at basahin nang sunod-sunod kung ano ang ginawa ng interface. Ang pagkakasunod-sunod na ito ang buong pagsisiyasat: pangyayaring DHCP bago ang paghinto, paghinto bago ang pangyayaring DHCP, at dalawang pangyayaring walang anuman sa pagitan ay tatlong magkakaibang natuklasan. Ang linyang log na binabanggit lamang ang lease habang nagre-reconnect na ang tunnel ay palamuti, hindi patunay.

Isulat ang timeline habang tumatakbo sa halip na itago sa alaala. Bihirang magtugma nang perpekto ang mga timestamp mula sa magkaibang tool, at kung minsan ang pagkakaiba mismo ang paliwanag.

Ihambing ang apat na halaga sa paligid ng pangyayari

Sapat na inilalarawan ng apat na halaga ang lokal na panig ng koneksyon upang mahuli ang tunay na pagbabago: address ng interface, default na gateway, listahan ng resolver at estado ng operasyon ng interface. Kunin ang mga ito sa loob ng isang minuto pagkatapos ng pagbagsak at ihambing sa capture na kinuha noong malusog ang tunnel.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Ang hindi nagbago na address na may hindi nagbago na gateway at binagong listahan ng resolver ay tumuturo sa paglutas ng pangalan at hindi sa routing, at maaaring nakaligtas ang tunnel habang tumigil ang mga aplikasyon sa paghahanap ng host. Ang binagong gateway ay nangangahulugang gumalaw ang daan palabas ng lokal na network, sapat na upang ipawalang-bisa ang rutang tumuturo sa nauna. Kung ang apat na halaga ay tumutugma sa malusog na capture, hindi ang lease ang sanhi mo at ang sariling lohika ng muling pagkonekta ng kliyente ang paksa. Kunin ang paghahambing habang nakikita ang depekto, dahil ang malusog na capture pagkatapos ng reboot ay may ibang kasaysayan ng address at hindi tutugma.

Ano ang mababago at hindi mababago ng renewal

RFC 2131 inilalarawan ang renewal bilang kahilingan sa orihinal na server sa kalahati ng oras ng lease, na may muling pag-binding sa anumang server sa pitong ikawalo kung walang sagot ang unang pagtatangka. Wala sa mga hakbang ang nag-aatas na makakuha ang kliyente ng ibang address, at karaniwang pinapalawig ng kooperatibong server ang umiiral na binding. Ang tunay na pagbabago ng address ay karaniwang dumarating sa ibang daan: tinatanggihan ng server ang renewal, nawala ng kliyente ang estado nito at nagsimula muli, o inilipat ng network ang device sa ibang segment.

Maaaring magbago ang pampublikong panig ng koneksyon nang walang anumang lokal na pagbabago. Sa likod ng carrier-grade na pagsasalin, ang address na nakikita ng peer ng VPN ay maaaring muling italaga nang malaya sa anumang ginawa ng lokal na lease, at ang muling pagtatalagang iyon ay mukhang katulad ng lokal na pagkabigo ng network mula sa loob ng kliyente. Ang paghahambing ng address na iniulat sa lokal laban sa obserbasyon mula sa panig ng peer ang tanging paraan upang paghiwalayin ang mga ito.

Kapag nabigo ang kliyenteng umangkop

Ang kliyenteng nagbigkis ng transport nito sa lumang address, nag-cache ng lumang ruta patungo sa peer o nagtago ng pagkakakilanlan ng interface ay maaaring magpatuloy sa pagsubok ng daang wala na. Depekto iyon sa pag-angkop, at nakikita ito bilang paulit-ulit na muling pagpapadala patungo sa address na hindi na maabot ng host. Ang ilang kliyente ay hinahawakan ito ayon sa disenyo: halimbawa, ina-update ng WireGuard ang endpoint ng peer kapag may dumating na tamang na-authenticate na packet mula sa bagong pinagmulan.

Ang manual na pag-restart na nagbabalik ng serbisyo ay palatandaan kung saan nabigo ang pag-angkop, hindi patunay na ang mga lease at tunnel ay hindi magkatugma. Panatilihin ang patakaran ng pagharang habang nagtetest, kung hindi ang test mismo ay nagiging pagkawala ng serbisyo na may ibang sanhi. Itala kung ang kliyente ay nakabawi nang mag-isa, gaano katagal, at aling address ang sinubukan muli; ang pagkakasunod-sunod na iyon ay nagsasabi ng higit pa kaysa sa dahilan ng paghinto na ipinapakita sa interface.

Ulitin ang pangyayari bago ito sisihin

Kopyahin ang kondisyon sa halip na maghintay sa iskedyul: bitawan at i-renew ang lease, o pilitin ang katumbas na kontroladong pangyayari, at obserbahan kung nakakaligtas ang tunnel. Sa pinamamahalaang network, i-coordinate ang anumang pagbabago ng address sa may-ari ng network, dahil ang di-makatwirang static na pagtatalaga ay maaaring mabangga sa device na mayroon na ng address na iyon.

Pagkatapos ng suportadong pagwawasto, ulitin ang parehong pangyayari at pagkatapos ay subukan ang isang aplikasyon at paghahanap ng pangalan, dahil ang tunnel na muling kumokonekta ngunit sinisira ang DNS ay pumasa sa mas mahinang test kaysa sa mahalaga. Iulat ang partikular na pagbabagong naobserbahan mo, kasama ang timestamp nito, sa halip na pangalanan ang naka-iskedyul na lease bilang sanhi. Ang pagkakaiba ng dalawang ulat ay kung ang susunod na tao ay makapagpaparami ng depekto o ng tsismis lamang.