Vai VPN pārstāj darboties pēc DHCP atjaunināšanas? Salīdziniet adreses

Nomas atjaunināšana un VPN kļūme žurnālos parādās kopā pietiekami bieži, lai cilvēki secinātu, ka viens izraisa otru. Laika sakritība ir īsta; cēloņsakarība parasti nav. Atjaunināšana ir unicast pieprasījums serverim, kas izsniedza nomu, ar lūgumu turpināt to pašu saistījumu, un serveris to var pagarināt, klientam nemainot nevienu adresi. Klienta pašu vērtību aplūkošana ap notikumu atdala klusi atjauninātu nomu no tīkla, kas patiešām mainījās zem darbojoša tuneļa.

Sāciet ar klientu, kas atkrita

Vispirms atveriet klienta savienojuma žurnālu un pierakstiet pārtraukuma laiku līdz sekundei. Pēc tam atveriet operētājsistēmas tīkla žurnālu tajā pašā minūtē un pēc kārtas izlasiet, ko darīja saskarne. Šī secība ir visa izmeklēšana: DHCP notikums pirms atvienošanās, atvienošanās pirms DHCP notikuma un divi notikumi bez nekā starp tiem ir trīs dažādi atradumi. Žurnāla rinda, kas tikai piemin nomu, kamēr tunelis jau atkal savienojās, ir dekorācija, nevis pierādījums.

Pierakstiet laika līniju gaitā, nevis turiet to atmiņā. Dažādu rīku laikspiedoli reti sakrīt pilnīgi, un pati novirze dažkārt ir izskaidrojums.

Salīdziniet četras vērtības ap notikumu

Četras vērtības pietiekami labi raksturo savienojuma lokālo pusi, lai uztvertu reālas izmaiņas: saskarnes adrese, noklusējuma vārteja, atrisinātāju saraksts un saskarnes darbības stāvoklis. Fiksējiet tās minūtes laikā pēc pārtraukuma un salīdziniet ar fiksāciju, kas veikta, tunelim esot veselam.

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

Nemainīta adrese ar nemainītu vārteju un mainītu atrisinātāju sarakstu norāda uz vārdu izšķiršanu, nevis maršrutēšanu, un tunelis varēja izdzīvot, kamēr lietojumprogrammas pārstāja atrast resursdatorus. Mainīta vārteja nozīmē, ka ceļš no vietējā tīkla ir pārvietojies, un ar to pietiek, lai atceltu maršrutu, kas norādīja uz iepriekšējo. Ja visas četras vērtības sakrīt ar veselo fiksāciju, noma nav jūsu cēlonis un par tēmu kļūst paša klienta atkārtotas savienošanas loģika. Fiksējiet salīdzinājumu, kamēr kļūme ir redzama, jo vesela fiksācija pēc pārstartēšanas ir ar citu adrešu vēsturi un nesakritīs.

Ko atjaunināšana var un ko nevar mainīt

RFC 2131 apraksta atjaunināšanu kā pieprasījumu sākotnējam serverim pusē nomas laika, ar pārsaistīšanu ar jebkuru serveri septiņās astotdaļās, ja pirmais mēģinājums paliek bez atbildes. Neviens solis neprasa, lai klients iegūtu citu adresi, un sadarbojošs serveris parasti pagarina esošo saistījumu. Īsta adreses maiņa parasti nāk pa citu ceļu: serveris atsakās atjaunināt, klients zaudēja savu stāvokli un sāka no jauna, vai tīkls pārvietoja ierīci uz citu segmentu.

Savienojuma publiskā puse var mainīties bez jebkādām lokālām izmaiņām. Aiz operatora līmeņa tulkošanas adresi, ko redz VPN partneris, var piešķirt no jauna neatkarīgi no tā, ko darīja vietējā noma, un šī pārpiešķiršana no klienta iekšpuses izskatās identiski kā vietēja tīkla kļūme. Vietēji ziņotās adreses salīdzināšana ar partnera puses novērojumu ir vienīgais veids, kā tās atdalīt.

Kad klients nespēj pielāgoties

Klients, kas saistīja savu transportu ar veco adresi, kešatmiņā saglabāja novecojušu maršrutu uz partneri vai saglabāja saskarnes identitāti, var turpināt mēģināt ceļu, kura vairs nav. Tas ir pielāgošanās defekts, un tas redzams kā atkārtotas pārsūtīšanas uz adresi, kuru resursdators vairs nevar sasniegt. Daži klienti to risina konstruktīvi: piemēram, WireGuard atjaunina partnera galapunktu, kad no jauna avota ierodas pareizi autentificēta pakete.

Manuāla pārstartēšana, kas atjauno pakalpojumu, ir norāde uz to, kur pielāgošanās neizdevās, nevis pierādījums, ka nomas un tuneļi nav savienojami. Testēšanas laikā saglabājiet bloķēšanas politiku, citādi pats tests kļūst par pārtraukumu ar citu cēloni. Pierakstiet, vai klients atguvās pats, cik ilgi tas prasīja un kuru adresi tas mēģināja vēlreiz; šī secība pasaka vairāk nekā saskarnē parādītais atvienošanās iemesls.

Atkārtojiet notikumu, pirms vainojat

Reproducējiet nosacījumu, nevis gaidiet grafiku: atbrīvojiet un atjauniniet nomu vai piespiediet līdzvērtīgu kontrolētu notikumu, un vērojiet, vai tunelis izdzīvo. Pārvaldītā tīklā saskaņojiet jebkuru adreses maiņu ar tīkla īpašnieku, jo patvaļīga statiska piešķiršana var sadurties ar ierīci, kurai šī adrese jau ir.

Pēc atbalstīta labojuma atkārtojiet to pašu notikumu un pēc tam pārbaudiet lietojumprogrammu un vārda vaicājumu, jo tunelis, kas atkal savienojas, bet salauž DNS, iztur vājāku testu nekā tas, kam ir nozīme. Ziņojiet par konkrēto novēroto izmaiņu ar tās laikspiedolu, nevis nosaucot ieplānoto nomu par cēloni. Atšķirība starp šiem diviem ziņojumiem ir tā, vai nākamais cilvēks spēs reproducēt kļūmi vai tikai baumas.