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

Поставете TLS обвивка пред OpenVPN и внедряването получава втори слушател, само един от които би трябвало някога да гледа към интернет. Когато тунелът работи от същата машина и се проваля отвън, пренасочването обикновено е насочено към грешния от двата. Това, което трябва да се подреди, е верига: публичното правило достига до обвивката, а собствената бекенд връзка на обвивката достига до истинския 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

Тези проби покриват бекенд сокета и дневника на обвивката, което отделя отказан бекенд от отхвърлено ръкостискане. Стартирайте ги, докато един опит е в ход, а не след това. Именно клеймата за време от един опит правят сравнението надеждно.

Две идентичности, два реда на отказ

Външният сертификат принадлежи на обвивката, а вътрешната идентичност — на 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