OpenVPN иза stunnel-а: проследите омотач, не порт 1194
Два пријемника, три порта. Проверите где смер стиже, где се омотач везује, где се спаја, шта је локални тест прескочио и оба идентитета.
Поставите TLS омотач испред OpenVPN и примена добија други пријемник, од којих би само један икада требало да гледа у интернет. Када тунел ради са исте машине, а не успева споља, смер је обично усмерен у погрешан од та два. Оно што мора да се поравна је ланац: јавно правило стиже до омотача, а сопствена backend веза омотача стиже до правог VPN сокета. Четири скока носе тај ланац и било који од њих може завршити истрагу прерано.
Два сокета, два власника, један од њих јаван
Омотач завршава TLS за спољну везу и предаје дешифрован ток бајтова обичном OpenVPN TCP пријемнику. То су одвојени сокети са одвојеним конфигурационим датотекама, па уређивање једног оставља други нетакнут и још увек наизглед здрав. То такође значи да се два могу разићи кад се један промени без другог.
Рад са саме машине зато доказује веома мало о јавном путу. Директна веза са матичним портом прескаче омотач, веза са омотачем на његовој LAN адреси прескаче превођење, и само потпуна поставка на страни клијента увежбава оно што ради спољни корисник. И имена треба читати пажљиво, јер localhost значи хост на ком се извршава тај конкретни компонент, а не хост на ком случајно куцате. Држите ту разлику у својим белешкама, јер тест забележен без скока који је покрио позива на поређење две различите ствари.
Где смер заиста стиже
Ланац је лакше држати као четири скока него као три броја портова, јер исти број може значити различите ствари на сваком крају. Читајте табелу ред по ред: сваки ред је један сокет који мора да прихвати везу и затим отвори следећу. Када је ред усмерен ка погрешном партнеру, симптом у последњој колони је оно што корисник пријављује.
| Hop | Listens on | Must reach | Symptom when it points elsewhere |
|---|---|---|---|
| Client machine | A local plaintext port | The wrapper's public TLS address | Plain text offered to a TLS endpoint |
| Router forward | Public TCP 443 | The wrapper host on its translated port | Wrapper records no connection at all |
| Wrapper, server mode | Its accepted port, 8443 here | The native VPN socket on loopback | Handshake completes, then silence |
| Native VPN listener | Loopback TCP port | Its peer, over TCP only | A UDP socket behind a byte-stream relay |
Правило које циља на изворни 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