Одбиена врска не е проблем со сертификатот: прирачник за VPN

Клиентот вели дека врската е одбиена веднаш откако сте го регенерирале CRL, па CRL изгледа виновен. Не е. Одбивањето е одговор на транспортниот слој, а проверката на сертификатот се случува подоцна, внатре во ракувањето на тунелот. Временското совпаѓање е контекст, не доказ.

Две проверки ги одвојуваат случаите за помалку од една минута и ниту една од нив не ги допира поставките за доверба.

Читајте ја грешката на слојот што ја создаде

ECONNREFUSED од connect значи дека транспортниот обид е одбиен: нешто одговори со reset или стекот пријави недостапен порт. Проблем со сертификатот не може да ја создаде таа грешка, бидејќи 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-ракувањето, откако спротивната страна ќе го претстави својот сертификат, и само ако конфигурацијата на серверот го овозможува тоа. Опцијата crl-verify на OpenVPN покажува на датотеката, а неуспехот се појавува во дневникот на серверот како грешка при проверка што го именува сертификатот.

Отповикан клиент затоа се поврзува на транспортниот слој и потоа не успева во автентикацијата. Ист сервер, ист порт, сосема друга порака.

Проверете го издавачот и датумите на важност на CRL кога ќе стигнете до таа фаза. CRL потпишан од погрешен CA, или оној што истекол пред клиентот да се поврзе, создава грешки при проверка што немаат никаква врска со сопствениот сертификат на клиентот.

Кратко упатство за следниот пат

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

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