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