OpenVPN падключаецца, але нічога не ідзе: знайдзіце ўзровень, дзе гінуць пакеты

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

Сокет або прывязаны, або не

Сэрвіс, які паведамляе пра актыўнасць, можа быць прывязаны да адраса або транспарту, які вы не планавалі. Запытайце сам сокет: ss -lunp пералічвае UDP-слухачоў, а ss -ltnp пералічвае TCP, і вартая чытання калонка гэта лакальны адрас, а не стан.

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

Перахапіце знешні пакет, а не тунэль

Фільтруйце на фізічным інтэрфейсе і рэальным порце, падставіўшы свой інтэрфейс: tcpdump -ni eth0 udp port 1194. Зыходныя пакеты, на якія нічога не вяртаецца, паказваюць на тое, што вышэй: фільтрацыя правайдэра, прылада NAT або аддалены адрас, які не той, пра які вы думаеце. Цішыня ў абодва бакі паказвае на кліенцкую маршрутызацыю або лакальны міжсеткавы экран. Адказы, што прыходзяць без прагрэсу тунэля, паказваюць на канал кіравання, гэта значыць на неадпаведнасць ключа або шыфра, а не на фільтрацыю.

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

Спачатку лічыльнікі, трасіроўка толькі калі яны хлусяць

Пачніце з лічыльнікаў, бо яны нічога не каштуюць. Альбо nft list ruleset, альбо iptables -L -n -v адказвае на адзінае пытанне, якое тут мае значэнне: ці супала правіла? Парадак вырашае вынік, бо першае супадзенне перамагае, і менавіта таму шырокі DROP перад пазнейшым ACCEPT пакідае гэты ACCEPT мёртвым і таму даданне правіла так рэдка нешта выпраўляе.

Прыналежнасць таксама блытае людзей. Ядро адносіць лакальна створаныя пакеты да працэсу, які адкрыў сокет, а OpenVPN звычайна працуе як root, таму правіла, прывязанае да звычайнага ID карыстальніка, ніколі не бачыць уласнага трафіку тунэля. Праверце UID уладальніка, перш чым вырашыць, што правіла няправільнае.

Толькі калі лічыльнікі застаюцца неадназначнымі, журнал варты шуму, і тады толькі для вузкага зрэзу: правіла iptables, якое абмяжоўвае хуткасць і дадае прэфікс да радкоў журнала, або правіла nftables з meta nftrace set 1 пры запушчаным nft monitor trace. Трасіроўка называе ланцужок і правіла, якое прыняло або скінула пакет. Пасля гэтага выдаліце абодва і трымайце журнал карыснай нагрузкі збоку.

Праверце таксама транспарт. Сэрвіс міжсеткавага экрана, абмежаваны TCP, нічога не кажа пра UDP-слухача на гэтым нумары, таму правіла, якое выглядае правільным, можа ўсё роўна скідваць кожны пакет.

Маршрутызацыя і шлях назад

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

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

Што павінен сказаць запіс

Для кожнага змянення запішыце этап, які вы праверылі, доказы, якія вы прачыталі, і значэнне лічыльніка з абодвух бакоў. Менавіта гэты запіс робіць "цяпер працуе" жыццяздольным на наступным аглядзе.

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