Valvo reitittimen VPN:ää luottamatta yhteen tilavaloon
Vertaisparin tila, valittu reitti ja sallittu sovellustesti vastaavat eri kysymyksiin. Hälytä rajalla, joka petti, älä vihreällä kuvakkeella.
Tilasivu sanoo yhdistetty, valo on vihreä, eikä toimisto tavoita tiedostopalvelinta. Toinen näistä tosiasioista koskee tunnelia ja toinen sen läpi kulkevaa polkua. Molempien valvonta on ero sellaisen hälytyksen välillä, johon voi reagoida, ja sellaisen, jonka oppii jättämään huomiotta.
Viisi tarkistusta järjestyksessä vertaisparista ulospäin.
Tarkistus 1: vertaisparin tai assosiaation tila
Jokainen protokolla paljastaa oman tilansa. WireGuard näyttää viimeisimmän kättelyn ja siirtolaskurit vertaisparia kohden komennolla wg show. OpenVPN kirjoittaa istunnon tilan tilatiedostoonsa tai hallintaliittymäänsä, ja IPsec paljastaa tietoturva-assosiaatiot työkaluilla kuten ipsec statusall. Ansana on lukea aikaleimaa tuomiona: joutilas WireGuard-vertaispari, jolla ei ole mitään lähetettävää, ei kättelisi äskettäin, eikä se ole katkos.
Vertaa aikaleimaa odotettuun liikenteeseen ja keepalive-asetuksiin ennen kuin kutsut ketään.
Tarkistus 2: valittu reitti
Tunneliliitäntä voi olla olemassa, vaikka mikään ei reitity siihen. Tarkista edelleenlähetystaulukko siitä kohteesta, jolla on sinulle merkitystä, ei tunnelin omasta aliverkosta. Jos etuliite puuttuu tai osoittaa muualle, vertaisparin tila on merkityksetön.
Tämä tarkistus nappaa vian, jota tilavalo ei koskaan näytä.
Hyödyllinen toinen tarkistus vertaa myös lähdeosoitetta. ip route get 10.20.5.10 palauttaa seuraavan hypyn, liitännän ja ensisijaisen lähteen, ja väärä lähde riittää katkaisemaan paluuliikenteen kaukopäässä. Kirjaa odotettu kolmikko kerran ja hälytä sitten, kun jokin osa muuttuu. Se yksi rivi nappaa NAT-muutokset, liitännän heilahtelut ja käytäntöpohjaisen reitityksen virheet.
Tarkistus 3: sallittu sovelluspolku
Testaa jotain, joka edustaa todellista vaatimusta. Reitittimestä lähtevä ping lähtee reitittimen omasta osoitteesta ja käytännöstä, jotka voivat poiketa edelleenlähetetystä LAN-liikenteestä, ja monet isännät rajoittavat ICMP:tä. Jos vaatimus on yksityinen palvelu, testaa sitä palvelua sen todellisessa portissa.
Pidä testin määrä maltillisena. Valvontasilmukan ei pitäisi tulla liikenteeksi, jota se mittaa.
Tarkistus 4: mikä muuttui ja milloin
Korreloi WAN-muutokset, avainten uusinnat, reittien poistot ja sovellusvirheet yhdelle aikajanalle. Erota tunnelivika varareitistä, joka palauttaa tavallisen internetyhteyden hiljaa, koska ne tuottavat samat käyttäjäraportit ja vastakkaiset diagnoosit. Aikavyöhykevirheet kääntävät järjestyksen, joten normalisoi ennen vertailua. Aikajana on se, mikä muuttaa neljä tarkistusta syyksi.
Säilytä lokit siirtymistä, älä hyötykuormasta.
Tarkistus 5: hälytyksen pitäisi nimetä raja
Hälytys, joka sanoo VPN alas, lähettää jonkun väärään paikkaan puolessa tapauksista. Hälytys, joka sanoo vertaisparin kättelyn olevan kaksitoista minuuttia vanhentunut, reitin 10.20.0.0/16 puuttuvan tai portin 445 testin epäonnistuvan, osoittaa tiettyyn tarkistukseen.
Pidä käyttölaskureita sen sijaan että selaisit hyötykuormia. Laskurit vastaavat valvontakysymykseen keräämättä sisältöä, jota et tarvitse.
Ja anna vikasietokäytännön päättää, mitä seuraavaksi tapahtuu. Valvonnan pitäisi tunnistaa, mikä raja petti, ei sallia laajaa ohitusta joka kerta, kun testi epäonnistuu. OpenVPN 2.6 -käsikirja dokumentoi tilatiedoston ja hallintaliittymän, jotka tekevät ensimmäisestä tarkistuksesta skriptattavan.