Miks teie VPN taastub kauem kui katkestus

Wi-Fi tuli tagasi kolmkümmend sekundit tagasi ja VPN on ikka maas, seega tundub klient katki. Sageli järgib see lihtsalt oma korduskatsete ajakava ja see ajakava ei tea, et võrk just tagasi tuli. See vahe ongi kogu lugu: taastumisaeg on katkestus pluss mis tahes ootamine, millega klient on juba arvestanud. Iga taimeri langetamine on üks vastus ja arusaamine, milline taimer loeb, on teine.

Kolm tingimust otsustavad, kas häälestamine aitab: milline etapp on aeglane, kas tõrge on üldse kordatav ja kuidas klient teada saab, et võrk on tagasi.

Kolm ootamist, mis näivad ühena

Lõpp-punkti tuvastamine, IKE või TLS läbirääkimine, pakettide kordussaade ja uue katse alustamine on eraldi sündmused eraldi taimeritega. strongSwan dokumenteerib kordussaate viivituse suurenemise IKE jaoks ja OpenVPN on oma korduskatsete juhtimine erineva semantikaga. Numbri kopeerimine ühest teise eeldab, et mehhanismid kattuvad, kuid need ei kattu. Lugege logi jada enne, kui otsustate, millist intervalli te vaatate.

Vaikne minut logis ei ole tingimata külmunud protsess. See võib olla eksponentsiaalne viivituse suurenemine, mis teeb täpselt seda, milleks see seadistati.

Milline etapp on tegelikult aeglane?

Kui logi näitab katseid, mis ebaõnnestuvad autentimisveaga, ei aita ükski taimeri muudatus, sest mandaat on vale. Kui katseid üldse ei tehta, on klient oma ooteaknas ja lahendus on ajakava. Kui katseid tehakse ja need aeguvad, on probleem kättesaadavuses või puuduvas kuulajas, ja kiirem kordamine ainult täidab logi. Kõigil neil kolmel olekul on erinev omanik ja ainult üks neist on ajastuse probleem.

Klassifitseerige tõrge enne, kui numbrit puudutate.

Millal taimeri langetamine aitab ja millal mitte

Langetage korduskatsete ülempiiri, kui domineeriv kulu on ootamine pärast lühikest ja sagedast katkestust, näiteks sülearvuti liikumine juurdepääsupunktide vahel. Jätke see rahule, kui tõrked on pikad või harvad, sest agressiivne kordamine lisab koormust täpselt sel hetkel, mil kontsentraator on kõige vähem võimeline vastama. Mõlemal juhul muutke ühte parameetrit, registreerige see ja mõõtke järgmist taastumist, selle asemel et eeldada paranemist.

Väga madal ajalõpp, mis on kopeeritud igasse profiili, on tavaline lõppseis mõõtmiseta häälestamisel.

Kontrollige valmisolekut enne, kui klienti süüdistate

Klient ei näe sageli, et võrk on kasutatav, enne kui miski proovib. Kinnistatud portaal, DHCP uuendamine või marsruudi muutus võivad jätta ta ootama ajakava, mis määrati enne kõige selle toimumist. Jälgige operatsioonisüsteemi võrguoleku muutust ja kliendi järgmist katset samal kellal ning näete, kelle ootamine see on. Kiire versioon on kirja panna võrgu-valmis sündmuse ajatempel ja esimese katse ajatempel pärast seda.

Kinnitage ka, et otsene liiklus on ootamise ajal endiselt blokeeritud, sest kiirem taastamine, mis lekitab liiklust, ei ole parendus.

Mida registreerida

Kirjutage üles, milline taimer muutus, millisest väärtusest millisesse, ja kuidas taastumine pärast välja nägi. Märkige ka kliendi versioon, sest vaikeväärtused liiguvad väljaannete vahel ja dokumenteerimata väga madal ajalõpp ajab segadusse järgmise inimese, kes profiili loeb.

See kirje muudab järgmise tarkvarauuenduse eksperimendi asemel võrdluseks.