Наблюдавайте 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 документира файла за състояние и интерфейса за управление, които правят първата проверка скриптуема.