OpenVPN усё яшчэ прасоўвае старыя маршруты? Праверце, што ён загрузіў

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

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

Файл, які вы адрэдагавалі, і файл, які чытае працэс

Пачніце з unit і каманднага радка, які ён спарадзіў. На хастэ з systemd systemctl cat openvpn@server друкуе радок ExecStart, а unit асобніка звычайна выводзіць шлях да канфігурацыі з назвы асобніка, таму дэман, запушчаны як openvpn@office, чытае іншы файл, чым запушчаны як openvpn@server. Параўнайце гэта з argv працуючага працэсу. Інструмент кіравання канфігурацыяй дадае яшчэ адзін спосаб страціць змену: ён можа запісаць правільны файл у месца, пра якое unit не згадвае, і тады ўдалы дэплой выглядае як бяздзейнасць.

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

Што сервер прасоўвае і што кліент усталёўвае

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

Файлы, прывязаныя да кліента, — частая крыніца блытаніны. Файл, названы па common name сертыфіката, прасоўвае параметры толькі гэтаму кліенту, і адрозненне ў адзін сімвал маўкліва спыняе прасоўванне, без памылкі з любога боку. Сервер запісвае ў журнал common name, які бачыў падчас злучэння, таму параўнайце гэта значэнне з назвай файла, а не з тым, як вы лічыце кліент называецца.

Прасунуты прэфікс і зваротны маршрут — розныя праблемы

Кліент, які свядома ігнаруе redirect-gateway, каб захаваць свой лакальны шлях у інтэрнэт, стварае другую, не звязаную з першай прагаліну. Зонды сервера дасягаюць адрасу тунеля, а адказы не прыходзяць, бо адказ, адрасаваны IP тунеля сервера, ідзе праз звычайны шлюз па змаўчанні кліента. Віны прасунутага маршруту падсеткі тут няма; не хапае маршруту, які накіроўвае трафік да сеткі тунеля сервера назад праз тунельнае прыстасаванне.

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

Параўнайце табліцы на абодвух канцах

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

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

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

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