Портът на VPN мълчи? Слушател, адрес за обвързване или защитна стена на хоста

VPN не отговаря нищо на порта си и двете възможни причини изискват противоположен ремонт: или нито един процес не е отворил сокета, или сокетът съществува и нещо между машините спира пакетите. Една команда решава първата половина от този въпрос, затова тя стои преди всяко правило на защитната стена. Редът по-долу премахва по едно обяснение на стъпка, вместо да добавя още едно предположение. Именно гадаенето между двете превръща десетминутна диагностика в цяла вечер.

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

Съществува ли сокетът изобщо

Започнете с това, което услугата казва за себе си: дали е стартирала и, по-полезното, каква е била първата й грешка при стартиране. Грешка при разбор, липсващ ключ или грешка при обвързване пречат на слушателя да съществува, а процесът може да излезе толкова тихо, че редът за състоянието да се чете двусмислено. Юнит, който се отчита като активен, не е доказателство сам по себе си, защото основният процес може да е жив, докато компонентът, който трябва да обвърже порта, вече се е отказал.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

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

На кой адрес и кое семейство отговаря сокетът

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

Ограничаването на списъка до един порт го запазва четим, когато хостът пуска няколко услуги. Филтърът sport взема порта заедно с транспорта, който тествате:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Колоната за протокол променя целия отговор

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

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

Един опит, три места за поглед

От одобрен клиент направете точно един опит и запишете времето до секундата. После прочетете три източника за този интервал: мрежовото правило или конзолата на доставчика, броячите или журнала на защитната стена на хоста и собствения журнал на услугата. Еднократното правене на това прави трите свидетелства сравними и струва по-малко от повтаряне на опит, чийто час никой не е записал.

Двата изхода сочат в противоположни посоки. Ако нито един пакет не е стигнал до хоста, пътят го изхвърля и слушателят е без значение. Ако пакетът е стигнал до сокета и услугата го е отхвърлила, пътят е наред и отговорът е в протокола, криптографията или идентификационните данни. Отварянето на порт за услуга, която вече е приела връзка, прави следващата диагностика по-трудна, а не по-лесна.

Да назовете етапа, преди да смените правило

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

Използвайте най-тясната диагностика, която отговаря на въпроса. Временно наблюдение на пакети на един порт под контрола на администратор е разумно средство; изключването на цялата защитна стена не е, защото резултатът става невъзможен за приписване. Документацията на ss покрива филтрите, използвани по-горе, и това е по-евтина първа стъпка от всеки захват. Запишете кой от двата клона доказахте и следващият случай започва от известен отговор.