OpenVPN efter stunnel: stjoer de ompakking troch, net poarte 1194
Twa lústerers, trije poarten. Kontrolearje wêr't de trochstjoering lânet, wêr't de ompakking him ferbynt, wêr't er ferbynt, wat in pleatslike test oersloech en beide identiteiten.
Set in TLS-ompakking foar OpenVPN en de útrôl kriget in twadde lústerer, wêrfan't mar ien ea it ynternet yn sjen moat. As de tunnel fan deselde masine wurket en fan bûten ôf mislearret, is de trochstjoering meastentiids op 'e ferkearde fan 'e twa rjochte. Wat klopje moat, is in keatling: de iepenbiere regel berikt de ompakking, en de eigen backend-ferbining fan 'e ompakking berikt de echte VPN-socket. Fjouwer sprongen drage dy keatling, en elkenien fan har kin it ûndersyk betiid einigje.
Twa sockets, twa eigners, ien fan har iepenbier
De ompakking einiget TLS foar de bûtenste ferbining en jout de ûntsifere bytestream troch oan in gewoane OpenVPN TCP-lústerer. Dat binne aparte sockets mei aparte konfiguraasjebestannen, dus it bewurkjen fan 'e iene lit de oare ûnoantaaste en noch altyd skynber sûn. It betsjut ek dat de twa útinoar drage kinne wannear't de iene sûnder de oare feroare wurdt.
Fan 'e masine sels ôf wurkje bewiist dêrom hiel lyts by de iepenbiere paad. In direkte ferbining nei de memmetaalpoarte slacht de ompakking oer, in ferbining nei de ompakking op syn LAN-adres slacht de oersetting oer, en allinnich de folsleine opset oan 'e klantkant oefenet wat in bûtensteander docht. Nammen moatte ek foarsichtich lêzen wurde, want localhost betsjut de host dy't dat bepaalde komponint draait, en net de host dêr't jo tafallich op type. Hâld dat ûnderskie yn jo notysjes, want in test dy't fêstlein is sûnder de sprong dy't er dekte, noeget út ta in ferliking tusken twa ferskillende dingen.
Wêr't de trochstjoering echt lânet
De keatling is makliker te hâlden as fjouwer sprongen as as trije poartnûmers, want itselde nûmer kin oan elk ein wat oars betsjutte. Lês de tabel rige foar rige: elke rige is ien socket dy't in ferbining akseptearje moat en dan de folgjende iepenje. As in rige op 'e ferkearde partner rjochte is, is it symptoom yn 'e lêste kolom wat de brûker rapportearret.
| 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 |
In regel dy't op 'e memmetaal VPN-poarte rjochte is ynstee fan op 'e ompakking, slacht de TLS-einigung hielendal oer, wat de meast foarkommende ferzje fan dizze flater is: de klant iepenet in hânskodding mei in lústerer dy't OpenVPN-raming ferwachtet, sadat de ferbining iepenje kin en dan fêst komt te sitten. Befêstigje de oersette poarte tsjin it konfiguraasjebestân fan 'e ompakking ynstee fan tsjin it ûnthâld, want de folgjende persoan dy't dat bestân bewurket, hat miskien in oar nûmer keazen. De twa kommando's hjirûnder litte beide kanten fan dy fraach tagelyk sjen.
grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'It bindadres dat jo wegeret
In accept-rige bûn oan 127.0.0.1 antwurdet allinnich de host sels, dus in trochstjoering dy't op it LAN-adres oankomt, kin net ferbine en de klant sjocht in wegering dy't klinkt as in pakketfilterprobleem. Sjoch nei de socket foardat jo de firewale oanreitsje, want de socket is it goedkeapere antwurd. Of bine de ompakking oan 'e ynterface dêr't de trochstjoering op rjochte is, of hâld it op loopback en meitsje dat de trochstjoering loopback berikt fia eat dat echt wurket. Dat binne twa ûntwerpen, en elk hat syn eigen regel nedich.
Se trochinoar mingje is hoe't in wurkjende ompakking fan bûten ûnberikber wurdt wylst elk bestân der goed útsjocht. De kontrôle hjirûnder is ien kommando, en it antwurdet in fraach dy't in resinsje fan 'e firewale-regels net kin. As de útfier in loopback-adres sjen lit wylst de trochstjoering op it LAN-adres rjochte is, heart de reparaasje yn 'e accept-rige en net yn it pakketfilter.
ss -lntp '( sport = :8443 )'Wat de pleatslike test echt bewiisde
In súkses dat fêstlein is sûnder de sprong dy't it dekte, is gjin bewiis oer de oare sprongen. Notearje hokker adres de test brûkte en hokker proses antwurde. Werhelje it dan fan bûten it netwurk ynstee fan fan in telefoan op deselde Wi-Fi, want hierspjelgedrach ferskilt tusken routers en in ferbining dy't it LAN nea ferliet, kin in klant tefreden stelle sûnder dat de trochstjoering der hielendal by belutsen is. Allinnich dy twadde poging oefenet it paad dat in frjemdling nimt.
As de poging mislearret, folgje ien ferbining oer beide logboeken: de akseptearre en ferbûne rigels fan 'e ompakking, dan it eigen sesjelogboek fan 'e VPN-daemon. De earste grins dy't neat fêstleit, is wêr't de folgjende feroaring heart. Sadree't OpenVPN peer-opsjes fergeliket, beoardielje dy berjochten neffens de regels fan dy ymplemintaasje. In warskôging oer link-mtu-ynkonsistinsje is net automatysk fataal, link-mtu op 1500 fêstsette bewiist net dat fragmintaasje ophâlden is, en siferûnderhanneling heart by de binnenste OpenVPN-konfiguraasje en net by de trochstjoering fan 'e router.
nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pagerDy sonden dekke de backend-socket en it logboek fan 'e ompakking, wat in wegere backend fan in wegere hânskodding skiedt. Rin se wylst in inkele poging ûnderweis is, net dêrnei. Tiidstimpels fan ien poging binne wat de fergeliking betrouber makket.
Twa identiteiten, twa flateroarders
It bûtenste sertifikaat heart by de ompakking en de binnenste identiteit heart by OpenVPN, en se kinne fan ferskate autoriteiten komme. It útskeakeljen fan ien fan 'e beide kontrôles om in paad sûn lykje te litten ruilet in echte beskerming foar in kosmetysk resultaat. Hâld beide ferifikaasjes en debug se yn oarder, want de folchoarder fan berjochten neamt de laach: in probleem mei it sertifikaat fan 'e ompakking ferskynt foardat ien VPN-opsje ûnderhannele wurdt, wylst in binnenste identiteitsflater pas ferskynt as de stream fêststeld is.
De stunnel-hânlieding definiearret accept, connect en de klantmodus presiis, en dy seksjes beantwurdzje de socketfraach flugger as rieden. As jo noch altyd net sizze kinne hokker laach antwurde, lês dan it sertifikaat dat de iepenbiere poarte presintearret mei it kommando hjirûnder. In sertifikaat fan 'e ompakking yn 'e útfier betsjut dat de trochstjoering de ompakking berikt hat, en stilte of in protokolfout betsjut dat net. Dat iene ûnderskie sparret mear tiid as hokker oare kontrôle hjir ek.
openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer