OpenVPN aiz stunnel: pārsūtiet apvalku, nevis 1194. portu

Novietojiet TLS apvalku OpenVPN priekšā, un izvietojums iegūst otru klausītāju, no kuriem tikai vienam jebkad vajadzētu būt vērstam pret internetu. Kad tunelis darbojas no tās pašas mašīnas un neizdodas no ārpuses, pāradresācija parasti ir vērsta uz nepareizo no diviem. Tam, kam jāsakrīt, ir ķēde: publiskais noteikums sasniedz apvalku, un paša apvalka backend savienojums sasniedz īsto VPN ligzdu. Četri lēcieni nes šo ķēdi, un jebkurš no tiem var pārtraukt izmeklēšanu agri.

Divas ligzdas, divi īpašnieki, viena no tām publiska

Apvalks pabeidz TLS ārējam savienojumam un nodod atšifrēto baitu plūsmu vienkāršam OpenVPN TCP klausītājam. Tie ir atsevišķas ligzdas ar atsevišķiem konfigurācijas failiem, tāpēc vienas rediģēšana atstāj otru neskartu un joprojām šķietami veselu. Tas nozīmē arī to, ka abas var attālināties viena no otras, kad vienu maina bez otras.

Darbs no pašas mašīnas tāpēc pierāda ļoti maz par publisko ceļu. Tiešs savienojums ar vietējo portu izlaiž apvalku, savienojums ar apvalku tā LAN adresē izlaiž tulkojumu, un tikai pilnīgs klienta puses izvietojums praktizē to, ko dara ārējais lietotājs. Arī vārdi jālasa uzmanīgi, jo localhost nozīmē resursdatoru, kurā darbojas tieši šī komponente, nevis to, kurā jūs nejauši ierakstāt. Saglabājiet šo atšķirību savās piezīmēs, jo tests, kas fiksēts, neatzīmējot to aptverto lēcienu, aicina salīdzināt divas dažādas lietas.

Kur pāradresācija patiešām nolaižas

Ķēdi vieglāk noturēt kā četrus lēcienus nekā kā trīs portu numurus, jo viens un tas pats numurs katrā galā var nozīmēt dažādas lietas. Lasiet tabulu rindu pēc rindas: katra rinda ir viena ligzda, kurai jāpieņem savienojums un pēc tam jāatver nākamais. Kad rinda ir vērsta uz nepareizo partneri, simptoms pēdējā kolonnā ir tas, par ko ziņo lietotājs.

Noteikums, kas vēršas pret vietējo VPN portu, nevis apvalku, pilnībā izlaiž TLS pabeigšanu, un tas ir visizplatītākā šīs kļūdas forma: klients atver rokas spiedienu ar klausītāju, kas gaida OpenVPN kadrējumu, tāpēc savienojums var atvērties un pēc tam apstāties. Pārbaudiet pārtulkoto portu pret apvalka konfigurācijas failu, nevis pret atmiņu, jo nākamais cilvēks, kas rediģēs šo failu, varbūt izvēlējās citu numuru. Divas komandas zemāk parāda abas šī jautājuma puses vienlaikus.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Piesaistes adrese, kas jūs noraida

Accept rinda, kas piesaistīta 127.0.0.1, atbild tikai pašam resursdatoram, tāpēc pāradresācija, kas ierodas uz LAN adresi, nevar savienoties un klients redz atteikumu, kas izklausās kā pakotņu filtra problēma. Paskatieties uz ligzdu pirms ugunsmūra aizskaršanas, jo ligzda ir lētākā atbilde. Vai nu piesaistiet apvalku saskarnei, uz kuru vērsta pāradresācija, vai turiet to uz loopback un panāciet, lai pāradresācija sasniegtu loopback caur kaut ko, kas patiešām darbojas. Tie ir divi projekti, un katram vajadzīgs savs noteikums.

To sajaukšana ir iemesls, kāpēc strādājošs apvalks kļūst nepieejams no ārpuses, kamēr katrs fails izskatās pareizs. Zemāk esošā pārbaude ir viena komanda, un tā atbild uz jautājumu, uz ko ugunsmūra noteikumu pārskats nevar atbildēt. Ja izvade rāda loopback adresi, kamēr pāradresācija vērsta uz LAN adresi, labojums pieder accept rindai, nevis pakotņu filtram.

ss -lntp '( sport = :8443 )'

Ko lokālais tests patiešām pierādīja

Panākumi, kas fiksēti, neatzīmējot to aptverto lēcienu, nav pierādījums par citiem lēcieniem. Pierakstiet, kādu adresi tests izmantoja un kurš process atbildēja. Pēc tam atkārtojiet no ārpuses ārpus tīkla, nevis no tālruņa tajā pašā Wi-Fi, jo matadatas uzvedība atšķiras starp maršrutētājiem, un savienojums, kas nekad nav atstājis LAN, var apmierināt klientu, pāradresācijai vispār nepiedaloties. Tikai šis otrais mēģinājums praktizē ceļu, ko iet svešinieks.

Kad mēģinājums neizdodas, sekojiet vienam savienojumam abos žurnālos: apvalka pieņemtajās un pievienotajās rindās, pēc tam VPN dēmona sesijas žurnālā. Pirmā robeža, kas neko nefiksē, ir vieta nākamajai izmaiņai. Kad OpenVPN sāk salīdzināt partnera opcijas, vērtējiet šos ziņojumus pēc šīs implementācijas noteikumiem. Brīdinājums par link-mtu neatbilstību nav automātiski nāvējošs, link-mtu piespraušana pie 1500 nepierāda, ka sadalīšana ir apstājusies, un šifra sarunas pieder iekšējai OpenVPN konfigurācijai, nevis maršrutētāja pāradresācijai.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Šīs zondes aptver backend ligzdu un apvalka žurnālu, kas atdala noraidītu backend no noraidīta rokas spiediena. Izpildiet tās, kamēr norisinās viens mēģinājums, nevis pēc tam. Viena mēģinājuma laikspiedoli padara salīdzinājumu uzticamu.

Divas identitātes, divas kļūmju secības

Ārējais sertifikāts pieder apvalkam, bet iekšējā identitāte pieder OpenVPN, un tie var nākt no dažādām iestādēm. Jebkuras no divām pārbaudēm izslēgšana, lai ceļš izskatītos vesels, apmaina reālu aizsardzību pret kosmētisku rezultātu. Saglabājiet abas pārbaudes un atkļūdojiet tās secībā, jo ziņojumu secība nosauc slāni: apvalka sertifikāta problēma parādās pirms jebkuras VPN opcijas apspriešanas, savukārt iekšējās identitātes kļūme parādās tikai pēc tam, kad plūsma ir izveidota.

stunnel rokasgrāmata precīzi definē accept, connect un klienta režīmu, un šīs sadaļas atbild uz ligzdas jautājumu ātrāk nekā minēšana. Kad vēl nevarat pateikt, kurš slānis atbildēja, izlasiet sertifikātu, ko uzrāda publiskais ports, ar zemāk esošo komandu. Apvalka sertifikāts izvadē nozīmē, ka pāradresācija sasniedza apvalku, un klusums vai protokola kļūda nozīmē, ka tā nesasniedza. Šī vienīgā atšķirība ietaupa vairāk laika nekā jebkura cita pārbaude šeit.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer