Pam mae eich VPN yn cymryd mwy o amser i wella na’r toriad

Daeth y Wi-Fi yn ôl dri deg eiliad yn ôl ac mae’r VPN yn dal i lawr, felly mae’r cleient yn edrych fel petai wedi torri. Yn aml mae’n dilyn ei amserlen ailgynnig ei hun, ac nid yw’r amserlen honno’n gwybod bod y rhwydwaith newydd ddod yn ôl. Y bwlch hwnnw yw’r stori gyfan: amser adfer yw’r toriad ynghyd ag unrhyw aros y mae’r cleient eisoes wedi ymrwymo iddo. Mae gostwng pob amserydd yn un ymateb, a deall pa amserydd sy’n bwysig yw’r llall.

Mae tair amod yn penderfynu a yw’r tiwtio’n helpu: pa gam sy’n araf, a yw’r methiant hyd yn oed yn ailgynnigadwy, a sut mae’r cleient yn dysgu bod y rhwydwaith yn ôl.

Tri aros sy’n edrych fel un

Datrys y pwynt terfyn, trafodaeth IKE neu TLS, ail-drosglwyddo pecynnau ac ychwyn ymgais newydd yn ddigwyddiadau ar wahân ag amseryddion ar wahân. Mae strongSwan yn dogfennu ôl-ôl ail-drosglwyddo ar gyfer IKE, ac mae OpenVPN yn rheoli ailgynnig ei hun gyda semanteg wahanol. Mae copïo rhif o’r naill i’r llall yn tybio bod y mecanweithiau’n cyfateb, ac nid ydynt. Darllenwch ddilyniad y log cyn penderfynu pa gyfwng rydych chi’n edrych arno.

Nid munud dawel mewn log yw proses rewedig o reidrwydd. Gall fod yn ôl-ôl esbonyddol yn gwneud yn union yr hyn y’i ffurfiwyd ar ei gyfer.

Pa gam sy’n araf mewn gwirionedd?

Os yw’r log yn dangos ymdrechion yn methu â gwall dilysu, ni fydd unrhyw newid amserydd yn helpu, oherwydd mae’r cymhwyster yn anghywir. Os nad oes ymdrechion yn cael eu gwneud o gwbl, mae’r cleient y tu mewn i’w ffenestr aros a’r ateb yw’r amserlen. Os gwneir ymdrechion ac maent yn dod i ben, y broblem yw cyrhaeddedd neu wrandawr ar goll, ac mae ailgynnig yn gyflymach yn llenwi’r log yn unig. Mae gan bob un o’r tri chyflwr hyn berchnogion gwahanol, a dim ond un ohonynt sy’n broblem amseru.

Dosbarthwch y methiant cyn cyffwrdd â rhif.

Pryd mae gostwng amserydd yn helpu, a phryd nad yw

Gostyngwch y terfyn uchaf ar ailgynigion pan mai’r gost amlycaf yw aros ar ôl toriad byr a mynych, fel gliniadur yn symud rhwng pwyntiau mynediad. Gadewch ef ar gyfer ei ben pan fo methiannau’n hir neu’n brin, oherwydd mae ailgynnig ymosodol yn ychwanegu llwyth ar yr union funud pan fo’r crynhodydd lleiaf abl i ateb. Yn y naill achos a’r llall, newidiwch un paramedr, cofnodwch ef, a mesurwch yr adferiad nesaf yn lle tybio ei fod wedi gwella.

Mae terfyn amser isel iawn a gopïwyd i bob proffil yn ganlyniad terfynol arferol tiwtio heb fesur.

Gwiriwch barodrwydd cyn beio’r cleient

Yn aml ni all y cleient weld bod y rhwydwaith yn ddefnyddiadwy nes bod rhywbeth yn ceisio. Gall porthladd caeth, adnewyddiad DHCP neu newid llwybr ei adael yn aros ar amserlen a osodwyd cyn i unrhyw un o’r rheini ddigwydd. Gwyliwch newid cyflwr rhwydwaith y system weithredu a’r ymgais nesaf gan y cleient ar yr un cloc, a gwelwch pa un yw’r aros. Y fersiwn gyflym yw nodi stamp amser y digwyddiad rhwydwaith-barod a stamp amser yr ymgais gyntaf ar ei ôl.

Cadarnhewch fod traffig uniongyrchol yn dal i gael ei rwystro yn ystod yr aros hefyd, oherwydd nid yw ailgysylltiad cyflymach sy’n gollwng traffig yn welliant.

Beth i’w gofnodi

Ysgrifennwch pa amserydd a newidiodd, o ba werth i ba werth, a sut olwg oedd ar yr adferiad wedyn. Nodwch fersiwn y cleient hefyd, oherwydd mae’r rhagosodiad yn symud rhwng rhyddhau ac fe fydd terfyn amser isel iawn heb ei ddogfennu yn drysu’r person nesaf sy’n darllen y proffil.

Mae’r cofnod hwnnw’n troi’r uwchraddiad meddalwedd nesaf yn gymhariaeth yn hytrach nag yn arbrawf.