OpenVPN се свързва, но нищо не тече: открийте слоя, където пакетът загива

OpenVPN казва, че е свързан, а трафик не се движи, изречение, което покрива поне пет несвързани повреди. Редактирането на правила на защитната стена, преди да знаете кой слой се проваля, умножава неизвестните и оставя на следващия инженер бъркотия. Вместо това работете от процеса навън, защото всяка стъпка по-долу или изчиства един етап, или стеснява мястото, където пакетът умира. Редът тук е важен: прихващане, направено преди да знаете кой адрес е вързан, ще докаже нещо, но не това, което ви трябва.

Сокетът или е вързан, или не е

Услуга, която съобщава, че е активна, може все още да е вързана към адрес или транспорт, които не сте предвиждали. Попитайте самия сокет: ss -lunp изброява UDP слушатели, а ss -ltnp изброява TCP, и колоната, която си струва да се чете, е локалният адрес, не състоянието.

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

Уловете външния пакет, не тунела

Филтрирайте по физическия интерфейс и реалния порт, като подставите своя интерфейс: tcpdump -ni eth0 udp port 1194. Изходящи пакети, на които нищо не се връща, сочат към това, което стои отгоре: филтриране на доставчика, устройство NAT или отдалечен адрес, който не е този, който мислите. Тишина в двете посоки сочи към клиентско маршрутизиране или локална защитна стена. Отговори, които пристигат без напредък на тунела, сочат към канала за управление, тоест несъответствие на ключ или шифър, а не към филтриране.

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

Първо броячите, проследяване само когато лъжат

Започнете с броячите, защото не струват нищо. Или nft list ruleset, или iptables -L -n -v отговаря на единствения въпрос, който има значение тук: съвпадна ли правилото? Редът решава изхода, защото първото съвпадение печели, поради което широк DROP преди по-късен ACCEPT оставя този ACCEPT мъртъв и поради което добавянето на правило толкова рядко поправя нещо.

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

Само когато броячите остават двусмислени, журналът си струва шума, и то само за тесен срез: правило на iptables, което ограничава скоростта и слага префикс на редовете си, или правило на nftables с meta nftrace set 1 при работещо nft monitor trace. Проследяването назовава веригата и правилото, което е приело или отхвърлило пакета. След това премахнете и двете и дръжте журнала на полезния товар извън него.

Проверете и транспорта. Услуга на защитна стена, ограничена до TCP, не казва нищо за UDP слушател на този номер, така че правило, което изглежда правилно, все още може да отхвърля всеки пакет.

Маршрутизиране и пътят обратно

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

На шлюз проверявайте препращането и веригата forward, а не веригата input. После потвърдете, че далечната страна знае как да достигне адреса на източника, защото работещ изходящ път без нищо връщащо се е тишина и в двата случая.

Какво трябва да каже записът

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

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