Ŝtopita VPN post restartigo de la enkursigilo: tri aferoj, kiuj ŝanĝiĝis

La enkursigilo finas la ekŝargon, la tekokomputilo reunuiĝas al la sama SSID, kaj la VPN restas ĉe konektita sen io ajn moviĝanta. La konservita profilo estas sendifekta. Kio eksvalidiĝis sub ĝi estis la vojo, kaj la kliento ankoraŭ tenas la staton, kiun ĝi konstruis por la malnova.

Tri kondiĉoj decidas la solvon. Kontrolu ilin laŭ ordo, ĉar la postaj estas vana laboro se la unua jam klarigas la halton.

Kondiĉo unu: la loka adreso ŝanĝiĝis

Restartigo povas doni al la maŝino alian adreson. Tiam VPN agordita kun fiksa loka finpunkto daŭre uzas aliĝon, kiu ne plu ekzistas. La samo validas por kliento, kiu ligis sian ingon al la malnova adreso. La tunela interfaco povas resti supre, dum ĉiu pako, kiun ĝi produktas, iras al nenie utila.

Komparu la adreson, kiun la kliento uzas, kun la adreso, kiun la interfaco nun havas. Defaŭlta itinero montranta al pordego, kiu ankaŭ ŝanĝiĝis, estas la sama speco de problemo sub alia nomo.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Kondiĉo du: la tradukita mapado malaperis

Hejmaj enkursigiloj tradukas elirantajn fluojn, kaj tiuj mapadoj vivas en la memoro. Restartigo forviŝas ĉiun el ili. Tio estas sendanĝera por nova konekto kaj fatala por tunelo, kiu kredas, ke ĝia ekzistanta fluo ankoraŭ validas. Tiam la alia flanko vidas nenion, do la kliento neniam ricevas eraron, pri kiu ĝi povus agi.

Ĝuste ĉi tie tunelo sen keepalive haltas silente anstataŭ malsukcesi laŭte. La dokumentitaj limigoj de WireGuard priskribas la saman formon de malsukceso. Malĝusta finpunkta stato produktas forĵetitajn pakojn anstataŭ diagnozon.

Daŭra keepalive de 25 sekundoj estas la kutima mildigo, ĉar ĝi refreŝigas la mapadon antaŭ ol senaktiva tempolimo povas eksvalidiĝi. Ĝi ne riparas mapadon, kiu jam malaperis. Parigu la keepalive kun rekonekta logiko anstataŭ trakti ĝin kiel riparon.

Kondiĉo tri: la publika adreso ŝanĝiĝis

Se la propra ekstera adreso de la enkursigilo ŝanĝiĝis, io ajn ĉe la alia flanko, kio filtras laŭ fonta adreso, nun vidas alian kunulon. La tunelo povas leviĝi kaj la servilo povas ankoraŭ forĵeti la trafikon, kio aspektas kiel rompita kliento kaj estas fakte politiko ĉe la alia fino.

Notu la eksteran adreson antaŭ kaj post la restartigo. Kiam la du malsamas, la demando moviĝas de la kliento al tiu, kiu prizorgas la permesliston, kaj restarigi la akreditaĵojn sur la tekokomputilo ne povas helpi.

Reparu laŭ la ĝusta ordo

Unue finu ajnan postulatan ensaluton ĉe kaptita portalo, poste lasu la klienton rekonektiĝi per sia subtenata proceduro anstataŭ mortigi la procezon. Observu, ĉu identeco kaj datuma trafiko ambaŭ revenas, ĉar tiuj estas du malsamaj stadioj de la sama konekto.

Kaŝmemorita paĝo pruvas nenion, nek babilaplikaĵo, kiu rekonektiĝis memstare. Testu la finpunkton, pri kiu vi vere zorgas, per freŝa peto. Tenu la rektan-trafikan politikon en vigoro dum la interrompo, ĉar rekonekta provo ne estas blokado.

Kiam tio ripetiĝas post ĉiu restartigo, la noto pli gravas ol la reprovo. Notu la lokan adreson, la pordegon, la eksteran adreson kaj la klientan staton antaŭ kaj post, poste komparu la du kolumnojn. Tio ŝanĝas malklaran plendon en vivciklan cimon, kiun iu povas ripari, kaj ĝi haltigas la trian anstataŭigon de la atestiloj pro mapada tempolimo.