Waarom jou VPN langer neem om te herstel as die onderbreking

Die Wi-Fi het dertig sekondes gelede teruggekom en die VPN is nog af, so die kliënt lyk stukkend. Dikwels volg dit sy eie herprobeerskedule, en daardie skedule weet nie dat die netwerk pas teruggekeer het nie. Daardie gaping is die hele storie: hersteltyd is die onderbreking plus enige wag waartoe die kliënt hom alreeds verbind het. Om elke timer te verlaag is een reaksie, en om te verstaan watter timer saak maak, is die ander.

Drie toestande bepaal of instelling help: watter fase stadig is, of die fout hoegenaamd herprobeerbaar is, en hoe die kliënt leer dat die netwerk terug is.

Drie wagte wat soos een lyk

Eindpuntbepaling, IKE- of TLS-onderhandeling, pakketherversending en om 'n nuwe poging te begin is afsonderlike gebeure met afsonderlike timers. strongSwan dokumenteer herversendingsbackoff vir IKE, en OpenVPN het sy eie herprobeerbeheer met ander semantiek. Om 'n getal van die een na die ander te kopieer, aanvaar dat die meganismes ooreenstem, en dit doen hulle nie. Lees die logreeks voordat jy besluit watter interval jy voor jou het.

'n Stil minuut in die log is nie noodwendig 'n gevriesde proses nie. Dit kan 'n eksponensiële terugtreding wees wat presies doen waarvoor dit opgestel is.

Watter fase is werklik stadig?

As die log wys pogings misluk met 'n verifikasiefout, help geen timerverandering nie, want die geloofsbrief is verkeerd. As daar glad geen pogings aangewend word nie, is die kliënt binne sy wagvenster en is die skedule die oplossing. As pogings aangewend word en tyd uitloop, is die probleem bereikbaarheid of 'n ontbrekende luisteraar, en vinniger herprobeer maak net die log vol. Elk van daardie drie toestande het 'n ander eienaar, en net een van hulle is 'n tydsberekeningprobleem.

Klassifiseer die fout voordat jy aan 'n getal raak.

Wanneer die verlaging van 'n timer help, en wanneer nie

Verlaag die herprobeerplafon wanneer die oorheersende koste wag is ná 'n kort, gereelde onderbreking, soos 'n skootrekenaar wat tussen toegangspunte beweeg. Laat dit alleen wanneer foute lank of skaars is, want aggressiewe herprobeer voeg las by juis die oomblik wanneer die konsentrator die minste in staat is om te antwoord. In beide gevalle verander een parameter, teken dit aan, en meet die volgende herstel in plaas daarvan om te aanvaar dit het verbeter.

'n Baie lae tydbeperking wat in elke profiel gekopieer word, is die gewone eindtoestand van instelling sonder meting.

Kontroleer gereedheid voordat jy die kliënt blameer

Die kliënt kan dikwels nie sien dat die netwerk bruikbaar is voordat iets dit probeer nie. 'n Vasgevangde portaal, 'n DHCP-hernuwing of 'n roeteverandering kan dit laat wag op 'n skedule wat opgestel is voordat enige van dit gebeur het. Kyk na die bedryfstelsel se netwerkstatusverandering en die kliënt se volgende poging op dieselfde horlosie, en jy sal sien wie se wag dit is. Die vinnige weergawe is om die tydstempel van die netwerk-gereed-gebeurtenis en die tydstempel van die eerste poging daarna neer te skryf.

Bevestig dat direkte verkeer ook tydens die wag steeds geblokkeer is, want 'n vinniger herverbinding wat verkeer lek, is nie 'n verbetering nie.

Wat om aan te teken

Skryf neer watter timer verander het, van watter waarde na watter waarde, en hoe herstel daarna gelyk het. Teken ook die kliëntweergawe aan, want verstekwaardes skuif tussen uitgawes en 'n ongedokumenteerde baie lae tydbeperking sal die volgende persoon wat die profiel lees, verwar.

Daardie rekord maak die volgende sagteware-opgradering 'n vergelyking eerder as 'n eksperiment.