Адмова ў злучэнні — гэта не праблема сертыфіката: кіраўніцтва па VPN

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

Дзве праверкі раздзяляюць выпадкі менш чым за хвіліну, і ні адна з іх не закранае налады даверу.

Чытайце памылку на тым узроўні, які яе стварыў

ECONNREFUSED ад connect азначае, што спроба транспарту была адхілена: нешта адказала скідам, або стэк паведаміў пра недасяжны порт. Праблема сертыфіката не можа даць такую памылку, бо TLS-рукапаціск ніколі не пачынаецца без транспартнага злучэння. Калі вы бачыце адмову, кліент не дайшоў да моманту прад’яўлення сертыфіката. Гэты адзіны факт выключае адкліканне як прычыну.

Слушна і адваротнае. Адкліканы сертыфікат дае завершанае TCP-злучэнне і няўдалы рукапаціск, які на серверы рэгіструецца як памылка праверкі.

Адмова TCP: ніхто не слухае

Для TCP праверце, ці працуе патрэбны экзэмпляр і ці прывязаны ён да адраса і порта з профілю. ss -lntp паказвае слухачоў, і іх адсутнасць — звычайнае тлумачэнне. Міжсеткавы экран, які адхіляе, а не адкідвае, дае такое ж паведамленне на баку кліента, таму правяраюць абодва.

Праверце таксама сямейства адрасоў. Сэрвіс, прывязаны да 127.0.0.1 або толькі да IPv6, адмовіць кліенту, які разрозніваецца ў іншы адрас.

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

У UDP няма рукапаціску, які можна адмовіць

OpenVPN праз UDP не ўсталёўвае злучэнне ў сэнсе TCP, таму ў момант connect няма чаго адмаўляць. У Linux памылка, якую паказвае UDP-сокет, можа паходзіць ад ICMP port-unreachable, згенераванага папярэдняй датаграмай. старонка даведкі udp(7) апісвае такія асінхронныя паводзіны.

Менавіта таму UDP-кліент можа выводзіць адмову, калі працэс сервера працуе, але не прывязаны да чаканага адраса.

Дзе CRL насамрэч правяраецца

CRL запытваецца падчас TLS-рукапаціску, пасля таго як суразмоўца прад’явіць свой сертыфікат, і толькі калі канфігурацыя сервера гэта дазваляе. Опцыя OpenVPN crl-verify спасылаецца на файл, а збой з’яўляецца ў журнале сервера як памылка праверкі з указаннем сертыфіката.

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

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

Кароткае кіраўніцтва на наступны раз

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

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