Порт 1194 вече се използва: кой притежава този OpenVPN сокет?

Стартирайте един и същ профил на сървъра два пъти и вторият процес излиза с грешка за зает адрес на порт 1194. В обичайния случай конфликтът е създаден от диагностичното стартиране, а оригиналната инстанция все още обслужва клиентите напълно нормално. Тази история обяснява голяма част от тези сигнали и си струва да бъде разпозната, преди нещо да бъде рестартирано. Това е и най-евтиният вариант за решаване.

Грешката описва локално свързване и нищо извън него. Тя не е доказателство, че доставчик блокира порта, че клиент е изпратил грешна парола или че веригата от сертификати е повредена.

Прочетете точната грешка при свързване

Две грешки от това семейство означават различни неща и объркването им ви отвежда на грешния слой. „Адресът вече се използва“ казва, че друг сокет държи поисканата крайна точка. „Адресът не е наличен“ казва, че поисканият адрес все още не съществува на този хост, което е проблем с готовността, а не дубликат.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Копирайте текста на грешката, преди да промените каквото и да е, включително адреса и порта, които тя посочва. Услуга, която чака да се появи интерфейс, ще записва втората грешка многократно и след това ще се свърже успешно, щом адресът съществува; услуга, която записва първата грешка, никога няма да успее, докато дубликатът не бъде решен. Записването коя от двете сте видели не струва нищо и спестява излишно търсене на интерфейс.

Направете опис на сокета, не на порта

Номерът на порта е непълен опис. Крайната точка е транспорт, семейство адреси, локален адрес и порт, всичко в едно мрежово пространство от имена. UDP слушател и TCP слушател на един и същ номер са различни сокети и два процеса на един и същ номер в различни пространства от имена никога не се срещат.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

Открийте кой процес го притежава

Числовите крайни точки плюс информацията за процеса идентифицират собственика, когато правата ви го позволяват, и собственикът е това, което ви трябва, а не името на програмата. Два OpenVPN процеса могат да работят с различни профили и този, който държи слушателя, може да е най-неочакваният.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

Един собственик или две проектирани инстанции

Ако внедряването предвижда един сървър, поддържайте един собственик на жизнения цикъл и четете журнала на тази инстанция или конфигурирания дневник, вместо да стартирате второ копие, за да я наблюдавате. Когато контролирано изпълнение на преден план е наистина необходимо, спрете управляваната инстанция умишлено и отчетете клиентите, които тя обслужва, преди да го направите.

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

Три преки пътя заслужават да бъдат назовани, защото се появяват във всяка тема за тази грешка. Не убивайте произволен PID, който изглежда виновен. Не включвайте споделяне на сокет, за да заглушите съобщението. Не превключвайте сървърен профил към несвързана конфигурация от клиентски тип, защото това кара грешката при свързване да изчезне; сървърът става недостъпен по начин, който е по-труден за диагностициране от първоначалния конфликт.

Смяната на порта е законен отговор само когато новият слушател е част от одобрен дизайн, който включва правилото за препращане и клиентската крайна точка. Ако те не са обновени, вие сте преместили конфликта на място, където никой не може да го намери.

Проверете свързването преди всичко друго

След ограничената корекция потвърдете, че предвидената инстанция е активна, че слушателят ѝ се появява на очаквания транспорт и че клиент може да се свърже. Успешното свързване завършва само етапа на локалния сокет; то не удостоверява нищо за удостоверяването или за трафика, след като тунелът е вдигнат.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

Ако сокетът присъства, а клиентът все още се проваля, останалият проблем е надолу по веригата и грешката при свързване вече е история. Това разделение е целият смисъл на това първо да прочетете точното съобщение: една грешка, един слой, един собственик. Прочетете го така и следващият симптом ще започне от известно състояние, а не от догадка.