Портата на 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 ги покрива филтрите користени погоре и е поевтин прв чекор од секое фаќање. Запишете која од двете гранки ја докажавте, и следниот случај започнува од познат одговор.