Uzraudzīt maršrutētāja VPN, neuzticoties vienai statusa lampiņai

Statusa lapa saka savienots, lampiņa ir zaļa, bet birojs nevar sasniegt failu serveri. Viens no šiem faktiem attiecas uz tuneli, otrs uz ceļu caur to. Abu uzraudzība ir atšķirība starp brīdinājumu, uz kuru varat reaģēt, un tādu, kuru iemācāties ignorēt.

Piecas pārbaudes, secībā, no vienādranga uz āru.

1. pārbaude: vienādranga vai asociācijas stāvoklis

Katrs protokols atklāj savu stāvokli. WireGuard rāda jaunāko rokasspiedienu un pārsūtīšanas skaitītājus katram vienādrangam, izmantojot wg show. OpenVPN raksta sesijas stāvokli savā statusa failā vai pārvaldības saskarnē, un IPsec atklāj drošības asociācijas ar tādiem rīkiem kā ipsec statusall. Slazds ir lasīt laika zīmogu kā spriedumu: dīkstāvē esošs WireGuard vienādrangs, kuram nav ko sūtīt, nesen nesaspiedīs rokas, un tas nav pārtraukums.

Salīdziniet laika zīmogu ar gaidīto datplūsmu un keepalive iestatījumiem pirms kāda izsaukšanas.

2. pārbaude: izvēlētais maršruts

Tuneļa saskarne var pastāvēt, kamēr tajā nekas netiek maršrutēts. Pārbaudiet pārsūtīšanas tabulu jums svarīgajam galamērķim, nevis paša tuneļa apakštīklam. Ja prefikss trūkst vai norāda citur, vienādranga stāvoklim nav nozīmes.

Šī pārbaude noķer kļūmi, ko statusa lampiņa nekad neparāda.

Noderīga otrā pārbaude salīdzina arī avota adresi. ip route get 10.20.5.10 atgriež nākamo lēcienu, saskarni un vēlamo avotu, un nepareizs avots ir pietiekams, lai attālinātajā galā salauztu atgriešanās datplūsmu. Vienreiz pierakstiet gaidīto trijnieku, pēc tam signalizējiet, kad mainās jebkurš elements. Šī vienā rinda noķer NAT izmaiņas, saskarnes svārstības un politikas maršrutēšanas kļūdas.

3. pārbaude: atļauts lietotnes ceļš

Pārbaudiet kaut ko tādu, kas pārstāv faktisko prasību. No maršrutētāja sūtīts ping iziet no paša maršrutētāja adreses un politikas, kas var atšķirties no pārsūtītās LAN datplūsmas, un daudzi resursdatori ierobežo ICMP. Ja prasība ir privāts pakalpojums, pārbaudiet šo pakalpojumu tā īstajā portā.

Turiet pārbaudes apjomu pieticīgu. Uzraudzības cilpa nedrīkst kļūt par datplūsmu, ko tā mēra.

4. pārbaude: kas mainījās un kad

Saistiet WAN izmaiņas, atslēgu atjaunošanu, maršrutu atsaukšanu un lietotņu kļūmes vienā laika skalā. Atšķiriet tuneļa kļūmi no rezerves maršruta, kas klusi atjauno parasto interneta piekļuvi, jo abi sniedz identiskus lietotāju ziņojumus un pretējas diagnozes. Laika joslas kļūdas apgriezīs secību, tāpēc normalizējiet pirms salīdzināšanas. Tieši laika skala pārvērš četras pārbaudes cēlonī.

Saglabājiet žurnālus pārejām, nevis lietderīgajai slodzei.

5. pārbaude: signālam jānosauc robeža

Signāls, kas saka VPN nestrādā, pusē gadījumu aizsūta cilvēku nepareizajā vietā. Signāls, kas saka vienādranga rokasspiediens novecojis divpadsmit minūtes, maršruts uz 10.20.0.0/16 nav vai pārbaude uz 445 portu neizdodas, norāda uz konkrētu pārbaudi.

Turiet darbības skaitītājus, nevis pārlūkojiet slodzes. Skaitītāji atbild uz uzraudzības jautājumu, nevācot saturu, kas jums nav vajadzīgs.

Un ļaujiet pārslēgšanas politikai izlemt, kas notiks tālāk. Uzraudzībai jānosaka, kura robeža sabojājās, nevis jāatļauj plaša apiešana katru reizi, kad pārbaude neizdodas. OpenVPN 2.6 rokasgrāmata dokumentē statusa failu un pārvaldības saskarni, kas ļauj pirmo pārbaudi veikt ar skriptu.