OpenVPN зад stunnel: проследете го обвиткувачот, не портата 1194

Поставете TLS обвиткувач пред OpenVPN и распоредувањето добива втор слушател, од кои само еден некогаш треба да гледа кон интернет. Кога тунелот работи од истата машина, а не успева однадвор, проследувањето обично е насочено кон погрешниот од двата. Она што мора да се подреди е синџир: јавното правило стигнува до обвиткувачот, а сопствената backend врска на обвиткувачот стигнува до вистинската VPN сокета. Четири скока го носат тој синџир и кој било од нив може да ја заврши истрагата рано.

Две сокети, два сопственици, едната јавна

Обвиткувачот завршува TLS за надворешната врска и го предава дешифрираниот бајтен тек на обичен OpenVPN TCP слушател. Тоа се одделни сокети со одделни конфигурациски датотеки, па уредувањето на едната ја остава другата недопрена и навидум здрава. Тоа исто така значи дека двете можат да се разидат кога едната се менува без другата.

Работата од самата машина затоа докажува многу малку за јавниот пат. Директна врска со матичната порта го прескокнува обвиткувачот, врска со обвиткувачот на неговата LAN адреса го прескокнува преводот, и само целосниот распоред од страната на клиентот го вежба она што го прави надворешен корисник. Имињата исто така треба внимателно да се читаат, зашто localhost значи хостот на кој работи токму таа компонента, а не хостот на кој случајно пишувате. Задржете ја таа разлика во вашите белешки, зашто тест забележан без скокот што го покрил поканува споредба на две различни работи.

Каде проследувањето навистина слетува

Синџирот полесно се држи како четири скока отколку како три броја на порти, зашто истиот број на секој крај може да значи различно. Читајте ја табелата ред по ред: секој ред е една сокета што треба да прими врска и потоа да ја отвори следната. Кога ред е насочен кон погрешниот партнер, симптомот во последната колона е она што го пријавува корисникот.

Правило што цели кон матичната VPN порта наместо кон обвиткувачот целосно го прескокнува завршувањето на TLS, што е најчестата форма на оваа грешка: клиентот отвора ракување со слушател што очекува OpenVPN врамување, па врската може да се отвори и потоа да застане. Потврдете ја преведената порта спрема конфигурациската датотека на обвиткувачот, а не спрема меморијата, зашто следниот човек што ќе ја уреди таа датотека можеби избрал друг број. Двете команди подолу ги покажуваат двете страни на тоа прашање истовремено.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Адресата на врзување што ве одбива

Accept ред врзан на 127.0.0.1 одговара само на самиот хост, па проследување што пристигнува на LAN адресата не може да се поврзе и клиентот гледа одбивање што звучи како проблем со пакетен филтер. Погледнете ја сокетата пред да го допрете огнениот ѕид, зашто сокетата е поевтиниот одговор. Или врзете го обвиткувачот на интерфејсот кон кој цели проследувањето, или задржете го на loopback и направете проследувањето да стигне до loopback преку нешто што навистина работи. Тоа се два проекта и секој бара своето правило.

Нивното мешање е начинот на кој работен обвиткувач станува недостапен однадвор додека секоја датотека изгледа исправна. Проверката подолу е една команда и одговара на прашање на кое прегледот на правилата на огнениот ѕид не може. Ако излезот покажува loopback адреса додека проследувањето цели кон LAN адресата, поправката припаѓа на accept редот, а не на пакетниот филтер.

ss -lntp '( sport = :8443 )'

Што навистина докажа локалниот тест

Успех забележан без скокот што го покрил не е доказ за другите скокови. Забележете која адреса ја користел тестот и кој процес одговорил. Потоа повторете надвор од мрежата, а не од телефон на истиот Wi-Fi, зашто однесувањето на шпенадата се разликува меѓу рутерите и врска што никогаш не ја напуштила LAN може да задоволи клиент без проследувањето воопшто да учествува. Само тој втор обид го вежба патот што го минува странец.

Кога обидот не успее, следете една врска во двата дневника: прифатените и поврзаните редови на обвиткувачот, потоа дневникот на сесијата на VPN демонот. Првата граница што ништо не запишува е местото на следната промена. Кога OpenVPN почнува да ги споредува опциите на партнерот, проценете ги тие пораки според правилата на таа имплементација. Предупредувањето за неусогласеност на link-mtu не е автоматски фатално, прицврстувањето на link-mtu на 1500 не докажува дека фрагментацијата запрела, а преговорот за шифра припаѓа на внатрешната конфигурација на OpenVPN, а не на проследувањето на рутерот.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Тие сонди ги покриваат backend сокетата и дневникот на обвиткувачот, што одвојува одбиен backend од одбиено ракување. Извршете ги додека еден обид е во тек, а не потоа. Временските ознаки од еден обид го прават споредувањето веродостојно.

Два идентитета, два реда на неуспех

Надворешниот сертификат му припаѓа на обвиткувачот, а внатрешниот идентитет на OpenVPN, и тие може да доаѓаат од различни органи. Исклучувањето на која било од двете проверки за патот да изгледа здрав ја менува вистинската заштита за козметичен резултат. Задржете ги двете проверки и отстранувајте ги по ред, зашто редоследот на пораките го именува слојот: проблемот со сертификатот на обвиткувачот се појавува пред да се преговара за која било VPN опција, додека внатрешниот идентитетски неуспех се појавува само откако ќе се воспостави текот.

прирачникот за stunnel прецизно ги дефинира accept, connect и клиентскиот режим, и тие делови одговараат на прашањето за сокетата побрзо од гаѓање. Кога сѐ уште не можете да кажете кој слој одговорил, прочитајте го сертификатот што го претставува јавната порта со командата подолу. Сертификат на обвиткувачот во излезот значи дека проследувањето стигнало до обвиткувачот, а тишина или грешка во протоколот значи дека не стигнало. Таа единствена разлика заштедува повеќе време од која било друга проверка овде.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer