OpenVPN agter stunnel: stuur die omhulsel deur, nie poort 1194 nie
Twee luisteraars, drie poorte. Kontroleer waar die deurstuur beland, waar die omhulsel bind, waar dit verbind, wat 'n plaaslike toets oorgeslaan het, en albei identiteite.
Plaas 'n TLS-omhulsel voor OpenVPN en die ontplooiing kry 'n tweede luisteraar, waarvan net een ooit die internet behoort te trotseer. Wanneer die tonnel van dieselfde masjien af werk en van buite af misluk, is die deurstuur gewoonlik op die verkeerde een van die twee gerig. Wat moet klop, is 'n ketting: die openbare reël bereik die omhulsel, en die omhulsel se eie backend-verbinding bereik die werklike VPN-sok. Vier spronge dra daardie ketting, en enigeen van hulle kan die ondersoek vroeg beëindig.
Twee sokkette, twee eienaars, een van hulle openbaar
Die omhulsel beëindig TLS vir die buitenste verbinding en gee die ontsluierde greepstroom aan 'n gewone OpenVPN TCP-luisteraar oor. Dit is afsonderlike sokkette met afsonderlike konfigurasielêers, so om een te wysig laat die ander onaangeraak en steeds skynbaar gesond. Dit beteken ook die twee kan uitmekaar dryf wanneer een sonder die ander verander word.
Om van die masjien self te werk, bewys dus baie min oor die openbare pad. 'n Direkte verbinding na die inheemse poort slaan die omhulsel oor, 'n verbinding na die omhulsel op sy LAN-adres slaan die vertaling oor, en net die volle kliëntkant-reëling oefen wat 'n buitestaander doen. Name moet ook noukeurig gelees word, want localhost beteken die gasheer wat daardie bepaalde komponent laat loop, en nie die gasheer waarop jy toevallig tik nie. Hou daardie onderskeid in jou notas, want 'n toets wat sonder die sprong wat dit gedek het, aangeteken is, nooi 'n vergelyking tussen twee verskillende dinge uit.
Waar die deurstuur werklik beland
Die ketting is makliker om as vier spronge te onthou as as drie poortnommers, want dieselfde nommer kan aan elke kant verskillende dinge beteken. Lees die tabel ry vir ry: elke ry is een sok wat 'n verbinding moet aanvaar en dan die volgende een moet oopmaak. Wanneer 'n ry op die verkeerde eweknie gerig is, is die simptoom in die laaste kolom wat die gebruiker rapporteer.
| 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 |
'n Reël wat op die inheemse VPN-poort eerder as op die omhulsel gerig is, slaan TLS-beëindiging heeltemal oor, wat die mees algemene weergawe van hierdie fout is: die kliënt begin 'n handdruk met 'n luisteraar wat OpenVPN-raamwerk verwag, so die verbinding kan oopgaan en dan vasval. Bevestig die vertaalde poort teen die omhulsel se konfigurasielêer eerder as teen geheue, want die volgende persoon wat daardie lêer wysig, het dalk 'n ander nommer gekies. Die twee opdragte hieronder wys albei kante van daardie vraag tegelyk.
grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'Die bindadres wat jou weier
'n Aanvaarlyn wat aan 127.0.0.1 gebind is, antwoord net die gasheer self, so 'n deurstuur wat op die LAN-adres aankom, kan nie verbind nie en die kliënt sien 'n weiering wat soos 'n pakkiefilterprobleem klink. Kyk na die sok voordat jy die vuurmuur aanraak, want die sok is die goedkoper antwoord. Bind die omhulsel óf aan die koppelvlak waarop die deurstuur gerig is, óf hou dit op loopback en laat die deurstuur loopback bereik deur iets wat werklik werk. Dit is twee ontwerpe, en elkeen het sy eie reël nodig.
Om hulle te meng, is hoe 'n werkende omhulsel van buite onbereikbaar eindig terwyl elke lêer korrek lyk. Die kontrole hieronder is een opdrag, en dit beantwoord 'n vraag wat 'n hersiening van die vuurmuurreëls nie kan nie. As die uitset 'n loopback-adres wys terwyl die deurstuur op die LAN-adres gerig is, hoort die regstelling in die aanvaarlyn en nie in die pakkiefilter nie.
ss -lntp '( sport = :8443 )'Wat die plaaslike toets werklik bewys het
'n Sukses wat aangeteken is sonder die sprong wat dit gedek het, is nie bewyse oor die ander spronge nie. Let op watter adres die toets gebruik het en watter proses geantwoord het. Herhaal dan van buite die netwerk eerder as vanaf 'n selfoon op dieselfde Wi-Fi, want haarspeldgedrag verskil tussen routers en 'n verbinding wat nooit die LAN verlaat het nie, kan 'n kliënt tevrede stel sonder dat die deurstuur hoegenaamd betrokke is. Net daardie tweede poging oefen die pad wat 'n vreemdeling volg.
Wanneer die poging misluk, volg 'n enkele verbinding oor albei logs: die omhulsel se aanvaarde en gekoppelde lyne, dan die VPN-daemon se eie sessielog. Die eerste grens wat niks aanteken nie, is waar die volgende verandering hoort. Sodra OpenVPN eweknie-opsies vergelyk, beoordeel daardie boodskappe volgens daardie implementering se reëls. 'n Waarskuwing oor link-mtu-teenstrydigheid is nie outomaties noodlottig nie, om link-mtu op 1500 vas te pen bewys nie dat fragmentering opgehou het nie, en syferonderhandeling hoort by die innerlike OpenVPN-konfigurasie eerder as by die router se deurstuur.
nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pagerDaardie peilings dek die backend-sok en die omhulsel-log, wat 'n geweierde backend van 'n verwerpte handdruk skei. Voer hulle uit terwyl 'n enkele poging aan die gang is, nie daarna nie. Tydstempels van een poging is wat die vergelyking betroubaar maak.
Twee identiteite, twee foutreekse
Die buitenste sertifikaat behoort aan die omhulsel en die innerlike identiteit behoort aan OpenVPN, en hulle kan van verskillende owerhede kom. Om enige van die twee kontroles af te skakel om 'n pad gesond te laat lyk, ruil 'n werklike beskerming vir 'n kosmetiese resultaat in. Hou albei verifikasies en ontfout hulle in volgorde, want die volgorde van boodskappe noem die laag: 'n probleem met die omhulsel-sertifikaat verskyn voordat enige VPN-opsie onderhandel word, terwyl 'n innerlike identiteitsfout eers verskyn sodra die stroom gevestig is.
Die stunnel-handleiding definieer aanvaar, verbind en kliëntmodus presies, en daardie afdelings beantwoord die sokvraag vinniger as raai. Wanneer jy nog steeds nie kan sê watter laag geantwoord het nie, lees die sertifikaat wat die openbare poort voorlê met die opdrag hieronder. 'n Omhulsel-sertifikaat in die uitset beteken die deurstuur het die omhulsel bereik, en stilte of 'n protokolfout beteken dit het nie. Daardie enkele onderskeiding spaar meer tyd as enige ander kontrole hier.
openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer