Набљудувајте VPN на рутерот без да и верувате на една светилка за статус
Состојбата на партнерот, избраната рута и дозволената проверка на апликација одговараат на различни прашања. Алармирајте на границата што паднала, а не на зелена икона.
Страницата за статус вели поврзано, светилката е зелена, а канцеларијата не може да стигне до датотечниот сервер. Еден од тие факти е за тунелот, а другиот за патеката низ него. Набљудувањето на двете е разликата помеѓу аларм на кој можете да дејствувате и таков што учите да го игнорирате.
Пет проверки, по ред, од партнерот кон надвор.
Проверка 1: состојба на партнерот или на асоцијацијата
Секој протокол ја изложува својата состојба. WireGuard го прикажува последното ракување и бројачите на пренос за секој партнер преку wg show. OpenVPN ја запишува состојбата на сесијата во својата датотека за статус или во управувачкиот интерфејс, а IPsec ги изложува безбедносните асоцијации преку алатки како ipsec statusall. Стапицата е да се чита временската ознака како пресуда: неактивен WireGuard партнер што нема што да испрати нема неодамна да се ракува, и тоа не е прекин.
Споредете ја временската ознака со очекуваниот сообраќај и поставките за keepalive пред да повикате некого.
Проверка 2: избраната рута
Интерфејс на тунел може да постои додека ништо не се рутира во него. Проверете ја табелата за препраќање за дестинацијата што ви е важна, а не за сопствената подмрежа на тунелот. Ако префиксот недостасува или покажува на друго место, состојбата на партнерот е неважна.
Таа проверка го фаќа дефектот што светилката за статус никогаш не го покажува.
Корисна втора проверка исто така ја споредува изворната адреса. ip route get 10.20.5.10 го враќа следниот скок, интерфејсот и преферираниот извор, а погрешен извор е доволен за да го прекине повратниот сообраќај на далечниот крај. Запишете ја очекуваната тројка еднаш, потоа алармирајте кога ќе се промени кој било елемент. Таа една линија ги фаќа промените на NAT, колебањата на интерфејсот и грешките во рутирање по политика.
Проверка 3: дозволена патека на апликација
Проверете нешто што е претставник на вистинското барање. Пингот од рутерот излегува од неговата сопствена адреса и политика, кои може да се разликуваат од препратениот LAN сообраќај, а многу домаќини го ограничуваат ICMP. Ако барањето е приватна услуга, тестирајте ја таа услуга на нејзиниот вистински порт.
Држете го обемот на проверката скромен. Надзорната јамка не треба да стане сообраќајот што го мери.
Проверка 4: што се промени и кога
Поврзете ги промените на WAN, обновувањето клучеви, повлекувањето рути и дефектите на апликациите на една временска линија. Разликувајте дефект на тунел од резервна рута што тивко го враќа обичниот пристап до интернет, бидејќи двете даваат идентични кориснички пријави и спротивни дијагнози. Грешките во временската зона ќе го свртат редоследот, затоа нормализирајте пред споредба. Временската линија е тоа што четири проверки ги претвора во причина.
Чувајте ги дневниците за премините, а не за товарот.
Проверка 5: алармот треба да ја именува границата
Аларм што вели VPN паднал половина од времето испраќа човек на погрешно место. Аларм што вели дека ракувањето на партнерот е старо дванаесет минути, рутата до 10.20.0.0/16 недостасува или проверката до портата 445 не успева, покажува на конкретна проверка.
Држете оперативни бројачи наместо да прелистувате товари. Бројачите одговараат на надзорното прашање без собирање содржина што не ви е потребна.
И нека политиката за префрлање одлучи што следи. Надзорот треба да утврди која граница паднала, а не да одобрува широко заобиколување секој пат кога проверката не успева. Прирачникот за OpenVPN 2.6 ги документира датотеката за статус и управувачкиот интерфејс што ја прават првата проверка скриптирана.