Отказана връзка не е проблем със сертификата: ръководство за 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 ръкостискането, след като отсрещната страна представи сертификата си, и само ако конфигурацията на сървъра го позволява. Опцията на OpenVPN crl-verify сочи към файла, а неуспехът се появява в журнала на сървъра като грешка при проверка, назоваваща сертификата.

Затова отменен клиент се свързва на транспортния слой и след това се проваля при удостоверяването. Същият сървър, същият порт, напълно различно съобщение.

Проверете издателя на CRL и датите на валидност, когато стигнете до този етап. CRL, подписан от грешен CA, или такъв, изтекъл преди клиентът да се свърже, дава грешки при проверка, които нямат нищо общо със собствения сертификат на клиента.

Кратко ръководство за следващия път

Първо потвърдете транспорта: има слушател, правилно семейство адреси, защитната стена не отхвърля. След това потвърдете, че услугата е стигнала до състояние на слушане, като прочетете журнала за стартиране. И едва тогава гледайте грешките при ръкостискане за съобщения за проверка. Дръжте този ред фиксиран, защото всяка стъпка елиминира цял клас причини.

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