Ĉu VPN senĉese malkonektiĝas? Trairu tion laŭ ĉi tiu ordo

Notu la intervalon, la eraron de la kliento kaj la staton de la reto antaŭ ol ŝanĝi ion ajn. La breĉo inter la malkonektiĝoj diras al vi kiun el kvar tavoloj kontroli.

Antaŭ ol reinstali la klienton, notu tri aferojn: kiom longe la tunelo restis supre, kion la kliento diris kiam ĝi falis, kaj ĉu la maŝino dormis aŭ ŝanĝis reton intertempe. Tiu noto estas la sola pruvo, kiun vi havos poste, kaj reinstalo kutime forviŝas ĝin. Falo je ripetiĝanta intervalo estas tempigilo aŭ finiĝo de stato; falo je hazarda momento estas problemo de la vojo. La ordo sube malhelpas vin ŝanĝi tri aferojn samtempe kaj lerni nenion.

Unua paŝo: registru la intervalon kaj la erartekston

Komencu per la propra protokolo de la kliento anstataŭ per la panelo de la provizanto. Ĉe Linux-kliento, la protokolo de la servo plus la viva stato de la tunelo kovras la plejparton:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Registru la tempomarkojn de la lasta sukcesa manpremo kaj la momenton, kiam la trafiko haltis, ne nur la momenton, kiam la ikono ŝanĝis koloron. GUI-kliento, kiu diras malkonektita post la fakto, eble raportas staton, kiun la kerno atingis sekundojn pli frue.

Konservu la vortigon de la eraro. Tempolimo, malakcepto de aŭtentikigo kaj adaptila aŭ pelila eraro montras al tri malsamaj tavoloj, kaj la plej granda parto de la malŝparita penado en ĉi tiu problemo venas de tio, ke oni traktas ilin kiel unu. Kopiu la linion laŭvorte en vian noton.

Dua paŝo: ŝanĝu unu variablon, ne la profilon

Tenu la aparaton kaj la profilon fiksaj kaj movu la maŝinon al alia alirreto, ekzemple poŝtelefona hotspot. Ĉi tio estas la plej malmultekosta testo, kiu apartigas la klienton de la vojo. Rulu ĝin sufiĉe longe por kovri la originalan fiaskintervalon; du stabilaj minutoj pruvas nenion pri falo, kiu okazas en la trideka minuto.

Tekkomputilo kun Ethernet-pordo donas al vi duan komparon, kiu tute forigas Wi-Fi el la bildo. Se la tunelo eltenas sur ambaŭ alternativoj, la originala alirreto meritas atenton: roaming inter alirpunktoj, hejma enkursigilo kies traduktabelo eksvalidiĝas, aŭ suprena ligilo, kiu restarigas longedaŭrajn fluojn.

Notu, kiun variablon vi ŝanĝis. Komparo validas nur kiam ĉio alia restis sama, kaj tio inkluzivas la servilan finpunkton kaj la horon de la tago.

Tria paŝo: mapu la intervalon al tavolo

La longo de bona sesio estas la plej informa ununura nombro, kiun vi havas. Legu ĝin kontraŭ ĉi tiu listo antaŭ ol tuŝi tempigilojn:

  • Falo post dormo aŭ rekomenco: la tunela stato travivis la paŭzon sed la interfaco ne. Kontrolu la konduton de la kliento pri rekonekto ĉe rekomenco kaj ĉu la servo restartigas la tunelon aŭ atendas trafikon.
  • Falo nur kiam ĝi estas senokupa: io en la mezo eksvalidigis la fluon. Ĝuste por tiu kazo ekzistas keepalive.
  • Falo je fiksa sesiaĝo: okazaĵo de reaŭtentikigo aŭ ŝlosilrenovigo, ne fiasko de la vojo. Klara malakcepto en la protokolo ĝuste je tiu intervalo estas la signo.
  • Falo dum grandaj transigoj aŭ grandaj paĝoj: suspektu MTU kaj fragmentadon, ne senokupan tempigilon.

Por la senokupa kazo, la agordoj dependas de la protokolo kaj ambaŭ flankoj gravas. La keepalive 10 60 de OpenVPN sur la servilo sendas pingon ĉiun 10 sekundojn kaj restartigas la ligilon post 60 sekundoj sen ĝi; WireGuard-klientoj malantaŭ NAT uzas PersistentKeepalive = 25 en la samtavola bloko. OpenVPN ankaŭ renegocas la datkanalon laŭ tempigilo, reneg-sec, kiu defaŭlte estas 3600 sekundoj en 2.x.

Ne kopiu agresemajn valorojn el la gvidilo de alia provizanto. Mallonga tempolimo sur perda poŝta ligilo produktas ĝuste la malkonektojn, kiujn ĝi devintus malhelpi, kaj valoroj senditaj de la servilo superregas tion, kion vi agordas en la klienta profilo.

Kvara paŝo: komparu unu subtenatan alternativon

Se la operatoro publikigas kaj UDP- kaj TCP-profilojn, rulu la saman aparaton kaj reton kontraŭ la alia. Uzu la efektivan kongruan dosieron anstataŭ redakti la transporton en kopiita profilo. Konstanta TCP-profilo sur vojo, kie UDP restariĝas, mallarĝigas la problemon al tiu vojo; ĝi ne pruvas, ke TCP estas la pli bona transporto ĉie.

La sama logiko validas por finpunktoj. Provu alian servilon kaj tenu la originalan rezulton apude. Se nur unu elirejo restarigas sesiojn, tio estas pruvo pri tiu finpunkto, ne kialo rekonstrui ĉiun adaptilon sur la tekkomputilo.

Post ajna ŝanĝo, ripetu la originalan ekigilon kaj konfirmu, kien la trafiko efektive iras. Reakirita interreta aliro ne estas la sama rezulto kiel trafiko ene de la tunelo, kaj kliento, kiu silente refalis al rekta vojo, aspektas sana el la retumilo.

Kontrolu la riparon kaj konservu la retroiron

Riparo estas kontrolata per reproduktado de la originala ekigilo, ne per sukcesa konekto. Lasu la tunelon senokupa preter la malnova fiaskintervalo, paŭzigu kaj rekomencu unufoje, kaj poste kontrolu la aĝon de la manpremo kaj la eliran adreson:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Tenu la antaŭan profilon kaj la antaŭajn tempigilajn valorojn ĝis la nova konduto postvivos plenan laboran tagon. Se la faloj revenas, restarigu la sekurkopion, poste reaplikuj la ŝanĝojn unuope, por ke la dua provo komenciĝu el konata stato.

Se la protokolo restas pura kaj la tunelo ankoraŭ falas je ripetiĝanta intervalo, la sekva halto estas la servila flanko por tiu sesio. Prenu kun vi la sesian identigilon de la kliento kaj la precizan falotempon, ĉar ĝuste tiu paro igas servilan protokolon serĉebla. La ligilaj opcioj de la protokolo estas dokumentitaj en la OpenVPN 2.6-manlibro kiam vi bezonas la precizan signifon de valoro.

Rilataj artikoloj