Сачыць за VPN на роўтары, не давяраючы аднаму індыкатару стану

Старонка стану кажа «падключана», індыкатар зялёны, а офіс не можа дасягнуць файлавага сервера. Адзін з гэтых фактаў пра тунель, другі — пра шлях праз яго. Назіранне за абодвума — гэта розніца паміж трывогай, на якую можна дзейнічаць, і той, якую вы навучыліся ігнараваць.

Пяць праверак, па парадку, ад партнёра вонкі.

Праверка 1: стан партнёра або асацыяцыі

Кожны пратакол паказвае ўласны стан. WireGuard паказвае апошні рукапаціск і лічыльнікі перадачы для кожнага партнёра праз wg show. OpenVPN запісвае стан сеансу ў файл стану або інтэрфейс кіравання, а IPsec паказвае асацыяцыі бяспекі праз такія інструменты, як ipsec statusall. Пастка — чытаць адзнаку часу як прысуд: прастойваючы партнёр WireGuard, якому няма чаго даслаць, не будзе рабіць рукапаціск нядаўна, і гэта не збой.

Параўнайце адзнаку часу з чаканым трафікам і наладамі keepalive, перш чым кагосьці выклікаць.

Праверка 2: выбраны маршрут

Інтэрфейс тунеля можа існаваць, пакуль у яго нічога не маршрутызуецца. Праверце табліцу перасылкі для патрэбнага вам пункта прызначэння, а не для ўласнай падсеткі тунеля. Калі прэфікс адсутнічае або паказвае ў іншае месца, стан партнёра не мае значэння.

Гэтая праверка ловіць збой, якога індыкатар стану ніколі не пакажа.

Карысная другая праверка таксама параўноўвае адрас крыніцы. ip route get 10.20.5.10 вяртае наступны крок, інтэрфейс і пераважную крыніцу, і няправільная крыніца дастатковая, каб зламаць зваротны трафік на далёкім баку. Запішыце чаканую тройку адзін раз, затым паведамляйце, калі зменіцца любы элемент. Гэты адзін радок ловіць змены NAT, ваганні інтэрфейса і памылкі маршрутызацыі па палітыцы.

Праверка 3: дазволены шлях праграмы

Праверце нешта рэпрэзентатыўнае для фактычнай патрэбы. Ping з роўтара выходзіць з яго ўласнага адраса і палітыкі, што можа адрознівацца ад перададзенага трафіку LAN, і многія хасты абмяжоўваюць ICMP. Калі патрэба — прыватная паслуга, тэстуйце гэтую паслугу на яе рэальным порце.

Трымайце аб'ём праверкі сціплым. Цыкл назірання не павінен стаць трафікам, які ён вымярае.

Праверка 4: што змянілася і калі

Звяжыце змены WAN, перазамену ключоў, адкліканне маршрутаў і збоі праграм на адной шкале часу. Адрозніце збой тунеля ад рэзервовага маршруту, які ціха вяртае звычайны доступ да інтэрнэту, бо яны даюць аднолькавыя скаргі карыстальнікаў і супрацьлеглыя дыягназы. Памылкі часавага пояса перавернуць парадак, таму нармалізуйце перад параўнаннем. Менавіта шкала часу ператварае чатыры праверкі ў прычыну.

Захоўвайце журналы для пераходаў, а не для карыснай нагрузкі.

Праверка 5: трывога павінна назваць мяжу

Трывога «VPN не працуе» пасылае чалавека не туды ў палове выпадкаў. Трывога «рукапаціск партнёра састарэў на дванаццаць хвілін», «маршрут да 10.20.0.0/16 адсутнічае» або «праверка порта 445 не ўдаецца» ўказвае на канкрэтную праверку.

Трымайце аперацыйныя лічыльнікі, а не праглядайце нагрузкі. Лічыльнікі адказваюць на пытанне назірання, не збіраючы змест, які вам не патрэбны.

І няхай палітыка пераключэння вырашае, што далей. Назіранне павінна вызначыць, якая мяжа зламалася, а не дазваляць шырокі абыход кожны раз, калі праверка не ўдаецца. Дапаможнік OpenVPN 2.6 апісвае файл стану і інтэрфейс кіравання, якія робяць першую праверку скрыптавальнай.