Kāpēc jūsu VPN atjaunojas ilgāk par pārtraukumu

Wi-Fi atgriezās pirms trīsdesmit sekundēm, un VPN joprojām ir izslēgts, tāpēc klients izskatās salūzis. Bieži tas vienkārši ievēro savu atkārtojumu grafiku, un šis grafiks nezina, ka tīkls tikko atgriezās. Šī plaisa ir viss stāsts: atjaunošanās laiks ir pārtraukums plus jebkura gaidīšana, kurai klients jau piekritis. Katra taimera samazināšana ir viena atbilde, un izpratne par to, kurš taimeris ir svarīgs, ir otra.

Trīs nosacījumi nosaka, vai regulēšana palīdzēs: kurš posms ir lēns, vai kļūme vispār ir atkārtojama, un kā klients uzzina, ka tīkls ir atgriezies.

Trīs gaidīšanas, kas izskatās kā viena

Galapunkta noteikšana, IKE vai TLS sarunas, pakešu atkārtota nosūtīšana un jauna mēģinājuma sākšana ir atsevišķi notikumi ar atsevišķiem taimeriem. strongSwan dokumentē atkārtotas nosūtīšanas atkāpšanos IKE, un OpenVPN ir savas atkārtojumu vadības ar citu semantiku. Skaitļa kopēšana no viena uz otru pieņem, ka mehānismi sakrīt, bet tie nesakrīt. Izlasiet žurnāla secību pirms izlemjat, uz kuru intervālu jūs skatāties.

Klusa minūte žurnālā ne vienmēr nozīmē iesalušu procesu. Tā var būt eksponenciāla atkāpšanās, kas dara tieši to, kam tā tika konfigurēta.

Kurš posms patiešām ir lēns?

Ja žurnāls rāda mēģinājumus, kas neizdodas ar autentifikācijas kļūdu, nekāda taimera maiņa nepalīdzēs, jo akreditācijas dati ir nepareizi. Ja mēģinājumi netiek veikti vispār, klients atrodas savā gaidīšanas logā, un grafiks ir risinājums. Ja mēģinājumi tiek veikti un tie beidzas ar noildzi, problēma ir sasniedzamībā vai trūkstošā klausītājā, un ātrāka atkārtošana tikai piepilda žurnālu. Katram no šiem trim stāvokļiem ir cits īpašnieks, un tikai viens no tiem ir laika problēma.

Klasificējiet kļūmi pirms pieskaraties skaitlim.

Kad taimera samazināšana palīdz un kad ne

Samaziniet atkārtojumu griestus, ja dominējošās izmaksas ir gaidīšana pēc īsa, bieža pārtraukuma, piemēram, klēpjdators, kas pārvietojas starp piekļuves punktiem. Atstājiet to mierā, ja kļūmes ir ilgas vai retas, jo agresīva atkārtošana pievieno slodzi tieši tajā brīdī, kad koncentrators spēj vismazāk atbildēt. Abos gadījumos mainiet vienu parametru, pierakstiet to un izmēriet nākamo atjaunošanos, nevis pieņemiet, ka tā uzlabojās.

Ļoti zems taimauts, kas nokopēts katrā profilā, ir ierastais regulēšanas bez mērījumiem gala stāvoklis.

Pārbaudiet gatavību pirms vainojat klientu

Klients bieži nevar redzēt, ka tīkls ir lietojams, kamēr kaut kas nepamēģina. Aizturēts portāls, DHCP atjauninājums vai maršruta izmaiņa var likt tam gaidīt grafiku, kas noteikts pirms visa tā. Vērojiet operētājsistēmas tīkla stāvokļa izmaiņas un klienta nākamo mēģinājumu tajā pašā pulkstenī, un jūs redzēsiet, kā gaidīšana tā ir. Ātrā versija ir pierakstīt tīkla-gatavības notikuma laikspiedolu un pirmā mēģinājuma pēc tā laikspiedolu.

Apstipriniet arī, ka tiešā satiksme gaidīšanas laikā joprojām ir bloķēta, jo ātrāka atkārtota savienošana, kas noplūdina satiksmi, nav uzlabojums.

Ko pierakstīt

Pierakstiet, kurš taimeris mainījās, no kādas vērtības uz kādu, un kā pēc tam izskatījās atjaunošanās. Pierakstiet arī klienta versiju, jo noklusējuma vērtības mainās starp laidieniem, un nedokumentēts ļoti zems taimauts sajaucīs nākamo cilvēku, kurš lasīs profilu.

Šis ieraksts pārvērš nākamo programmatūras atjauninājumu salīdzinājumā, nevis eksperimentā.