Maršrutizatoriaus VPN atrodo gerai po elektros dingimo? Patikrinkite šiuos keturis sluoksnius

Maršrutizatorius, kuris po dingimo užsidega, atkūrė savo konfigūraciją, o ne ryšį. Po elektros dingimo maršrutizatorius gali atkurti išsaugotą VPN profilį anksčiau, nei bus paruoštos to profilio reikalingos priklausomybės: modemas aukščiau gali vis dar treniruotis, laikrodis gali būti neteisingas, o autentifikacija gali būti nebaigta. Skydelio lemputė ir išsaugota konfigūracija apibūdina ketinimą, o ne veikiantį tunelį. Patikrinkite keturis sluoksnius žemiau iš eilės, o ne keiskite profilį, nes tai žmonės daro antruoju ir gailisi pirmiausia.

Viskas čia daro prielaidą, kad esate vietoje arba turite patekimo kelią, kuris nepriklauso nuo tunelio, kurį testuojate. Jei ne, sutvarkykite tai prieš kitą dingimą.

Pirmas sluoksnis: ar WAN tikrai grįžo

Pradėkite nuo modemo, o ne nuo maršrutizatoriaus skydelio. Maršrutizatorius, kuris baigia įkrovimą anksčiau, nei jo modemas pasitreniravo, rodo sveiką sąsają be nieko už jos, o tunelis neturi partnerio, kurį pasiektų. Patvirtinkite, kad modemas tikrai persiunčia, tada patvirtinkite, kad maršrutizatorius gavo laukiamus WAN nustatymus. Patikrinkite ir ar nepasikeitė WAN adresas: dinaminis adresas, kuris grįžta kitoks, gali panaikinti adresu pagrįstą taisyklę arba nuotolinį leidžiamų sąrašą, o iš tinklo vidaus tai atrodo kaip VPN gedimas.

Kai kurie prieigos tinklai po dingimo taip pat reikalauja naujo priėmimo veiksmo. Skaitykite kliento žurnalą, kad rastumėte pirmą nesėkmės etapą, o ne spėliokite: pirmoji klaida įvardija sluoksnį, o viskas po jos yra pasekmė. Užrašykite adresą ir priėmimo rezultatą biliete, nes abu lemia, ar tas pats profilis veiks rytoj. Pasikeitęs adresas yra penkių minučių taisymas ir dviejų valandų mįslė.

Antras sluoksnis: patikrinkite laikrodį prieš sertifikatą

Neteisingas laikrodis trukdo sertifikato galiojimui ir viskam, kas pagrįsta laiku, o įterptas įrenginys, kuris įsibėgėja be veikiančio laiko šaltinio, gali kurį laiką likti prie senos datos. Tada sertifikato patikra nepavyksta dėl priežasties, kuri neturi nieko bendro su prisijungimo duomenimis. Galiojimo klaida, kurios datos nukrypę metais, nurodo laikrodį; ta pati klaida su dabartinėmis datomis nurodo sertifikatą.

date -u
chronyc tracking

Naudokite palaikomą laiko atkūrimo procesą ir patvirtinkite maršrutizatoriaus laikrodį prieš liesdami profilį. Patikros išjungimas, norint apeiti klaidą, laikiną tvarkos problemą paverčia nuolatiniu susilpnėjimu, ir tai yra dažniausia bloga pataisa šiame scenarijuje. Jei įrenginys neturi laikrodžio su baterija, įkrovimo tvarka svarbi: jam reikia tinklo prieigos prieš sinchronizuojant laiką ir laiko prieš patvirtinant tunelį. Būtent tą tvarką reikia taisyti, jei ta pati nesėkmė kartojasi po kiekvieno dingimo.

Trečias sluoksnis: perskaitykite, ką sako tunelis

Patikrinkite pačio tunelio būseną ir jo rankos paspaudimo ar autentifikacijos rezultatą, o ne tai, ar sąsaja pakilo. Sąsaja gali egzistuoti be nustatyto partnerio, o klientas gali rodyti prisijungusį, nors raktų atnaujinimas nepavyksta. Atskirkite transporto laiko limitus nuo aiškių atmetimų: laiko limitas leidžia manyti, kad kelias ar partneris dar nepasiekiami, o atmetimas reiškia, kad tolimasis galas atsakė ir atsisakė, dažniausiai dėl prisijungimo duomenų, sertifikato ar partnerio tapatybės, kuri nebeatitinka. Siųsti naudotoją atkurti slaptažodžio dėl laiko limito yra švaistyti visų popietę.

Laikykite paskutinę žinomą gerą konfigūraciją po ranka, kad palygintumėte laukus, o ne juos atkurtumėte. Jei laukas pasikeitė, tas pokytis ir yra radinys. Palyginkite jį laukas po lauko su atkurta konfigūracija, o ne skaitykite tik atkurtą. Dauguma netikėtumų po dingimo yra laukas, kuris tyliai grįžo prie šablono numatytosios reikšmės.

Ketvirtas sluoksnis: testuokite iš įrenginio žemiau

Atidarykite nekenksmingą leidžiamą išteklių iš kliento už maršrutizatoriaus, tada patvirtinkite, kurį išėjimą ar privatų maršrutą srautas tikrai naudojo. Patikrinkite DNS ir kiekvieną adresų šeimą, kurią teigiate apimantys, nes paties maršrutizatoriaus patikra gali pavykti, nors kliento politika dar neteisinga — patikra dažnai naudoja kitą šaltinį, kitą lentelę ar kitą sprendėjo kelią.

curl -s https://ifconfig.me
nslookup example.com

Jei tunelis neveikia ir tai ne tik neteisinga konfigūracija, nuspręskite, ar paveikti klientai turi būti blokuojami, ar gali naudoti patvirtintą atsarginį variantą. Šis pasirinkimas priklauso perjungimo planui prieš dingimą, o ne pokalbių gijai jo metu. Įrašykite stebėtą išėjimą ir sprendėją į dingimo bilietą. Dvi eilutės dabar sutaupo kitam žmogui valandą spėlionių, kuris kelias buvo aktyvus tuo metu.

Ką pataisyti, kad kitas dingimas būtų trumpesnis

Jei nesėkmė kartojasi, pataisa yra tvarka, o ne konfigūracija: pakelkite WAN, tada laiką, tada tunelį, tada kliento politiką. Dauguma maršrutizatorių tai išreiškia kaip priklausomybę ar delsimą, o trumpas sąmoningas delsimas geriau nei profilio perrašymas.

Tada pakartokite įprastą paleidimo testą po pakeitimo, įskaitant patikrą kliento pusėje. Paleidimo testas, kuris žiūri tik į maršrutizatoriaus skydelį, tikrina mažiausiai informatyvų iš keturių sluoksnių.