Kial via VPN falas ĉiufoje, kiam la ŝlosiloj rotacias

La konekto funkcias dum unu horo kaj poste mortas, kaj la kliento raportas nenion pli utilan ol disconnected. Tiu periodo estas la ŝlosilo, ĉar io en la renoviga interŝanĝo diferencas de la unua manpremo. La tempilo nur decidas, kiam vi renkontos ĝin. Konservu la mesaĝojn de tiu interŝanĝo anstataŭ la finan etikedon.

Legu la etapon, ne la etikedon

En IKEv2 la IKE-asocio kaj la CHILD-asocio renoviĝas laŭ apartaj horaroj. Propono, kiu estis akceptebla por la unua intertraktado, ne estas aŭtomate akceptebla por la dua. Unu povas finiĝi dum la alia estas rifuzata, kio produktas tunelon, kiu duone ekzistas. Kaptu la interŝanĝon per la ilo, kiu posedas ĝin, anstataŭ per klienta protokollinio:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

Por OpenVPN la ekvivalenta evento estas reintertraktado regata de la versio kaj la deplojaj agordoj. Ĝia aŭtentiga konduto havas proprajn fiaskreĝimojn. La mesaĝo, kiu gravas, nomas la fiaskintan etapon, kaj vi devus registri ĝin laŭvorte anstataŭ reverki ĝin en bileton.

Notu ankaŭ la tempomarkojn. Falo je fiksa intervalo post la lasta sukcesa intertraktado estas tute alia konkludo ol tiu, kiu venas hazarde dum uzo, kaj la intervalo ofte estas la sola pruvo, kiu postvivas.

Komparu la proponon, kiu fiaskas

Rifuzita propono produktas klaran mesaĝon ĉe la respondanto. La kutima kaŭzo estas diferenco inter la du finoj en algoritmo, ŝlosillongo, grupo aŭ vivodaŭro. La unua CHILD-intertraktado povis sukcesi, ĉar ĝin iniciatis la alia flanko, kio signifas, ke ĝi uzis la proponliston de la alia flanko. Rigardu ambaŭ finojn antaŭ ol ŝanĝi ion.

Miskongruoj de vivodaŭro meritas specialan atenton, ĉar valoro, kiu ŝajnis malavara ĉe unu fino, povas igi la alian finon komenci renovigon, kiun ĝi ne povas fini. La dokumentaro pri ŝlosilrenoviga konduto priskribas, kiel asocia renovigo estas ekigita kaj kiel la du finoj povas diferenci en siaj tempaj atendoj. Komparu, kion ĉiu fino asertas subteni, anstataŭ kion sugestas la agorda dosiero.

Malnova profilo aŭ provizanta ŝablono povas fiksi proponon, kiun la nuna eldono ne plu proponas. La miskongruo montriĝas nur, kiam nova intertraktado estas devigita.

Apartigu akreditan problemon de neatingebla samtavolano

Renovigo, kiu fiaskas ĉe aŭtentigo, aspektas simile en la kliento kaj tute alie sur la servilo. Se akreditaĵo estas rekontrolata ĉe reintertraktado, eksvalidiĝinta atestilo, revokita konto aŭ ŝanĝita pasvorto produktos falon ĝuste je la renoviga intervalo, dum ĉiu antaŭa konekto sukcesis. Neatingebla samtavolano estas la tria ebleco, kaj ĝi produktas neniun rifuzon: la pakaĵoj foriras kaj nenio respondas. Tiu kazo kutime sekvas retan ŝanĝon anstataŭ tempilon, do kontrolu, ĉu la fiasko sekvas vagadon, senaktivan periodon aŭ vojŝanĝon.

Distingi la tri per tio, kion protokolis la fora fino. Rifuzo kun kaŭzo, aŭtentiga fiasko kaj silento estas tri malsamaj korektoj. Restartigi la klienton kunfalas ilin en unu senutilan observon.

Kontrolu la atestildatojn kaj la kontostaton antaŭ ol kulpigi la reton. Ambaŭ estas malmultekostaj por inspekti kaj ambaŭ estas nevideblaj en la propra mesaĝo de la kliento.

Devigu unu renovigon kaj legu la rezulton

Devigu unu renovigon per la subtenata metodo de la operatoro anstataŭ atendi horon por la sekva. Konservu la postulatan fiaskpolitikon sendifekta dum vi faras tion. Malŝalti kontroladon aŭ streĉi vivodaŭrojn ĝis tago igas la simptomon malaperi el viaj protokoloj sen korekti ion. Ĝi ankaŭ lasas pli longan interrompon atendantan la sekvan homon.

Post kiam riparo estas en loko, kontrolu la renovigitan tunelon kaj poste faru novan peton el la aplikaĵo. Aplikaĵa seanco, kiu vivis kiam la asocio ŝanĝiĝis, eble bezonas sian propran reakiron, eĉ se la tunelo denove sanas. Uzantoj raportos tion kiel VPN ankoraŭ rompita.

Registru la eldonversiojn, la intertraktitajn tempilojn kaj la etapon, kiu fiaskis. La sekva ripeto tiam povas esti komparata kun ĉi tiu anstataŭ priskribi ĝin denove el memoro.