Одбијена веза није проблем сертификата: приручник за 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, или онај који је истекао пре него што се клијент повезао, производи грешке провере које немају никакве везе са клијентовим сопственим сертификатом.

Кратак приручник за следећи пут

Прво потврдите транспорт: слушалац присутан, исправна фамилија адреса, заштитни зид не одбија. Затим потврдите да је сервис достигао стање слушања читајући дневник покретања. Па тек онда гледајте грешке руковања у потрази за порукама провере. Држите тај редослед фиксним, јер сваки корак искључује целу класу узрока.

Запишите транспорт, разрешено одредиште, порт и тачан текст грешке. Поновна инсталација клијента уништава тај доказ и обично ништа не мења.