OpenVPN un HTTPS 443. portā: kam pieder klausītājs?
TCP un UDP 443 ir atsevišķas ligzdas. Lai dalītu vienu TCP klausītāju, vajadzīgs īpašnieks, un OpenVPN porta dalīšana ir šaurs nolīgums, nevis starpniekservera triks.
Divi pakalpojumi var abi atbildēt portā 443, nekad nekonkurējot, jo klausītāju nosaka transports, adrese un ports kopā, nevis tikai numurs. Ielieciet tīmekļa serveri un OpenVPN vienā mašīnā, un vienīgais jautājums, uz kuru ir vērts atbildēt vispirms, ir tas, kādu ligzdu katrs process prasa no kodola. Pierakstiet šo sarakstu pirms konfigurācijas rediģēšanas, un lielākā daļa kļūdu «adrese jau tiek izmantota» izskaidrosies pašas. Viss pēc saraksta ir izvēle starp UDP klausītāju, kopīgu TCP ligzdu vai priekšgalu, kas maršrutē pēc protokola.
Sāciet ar ligzdu, ko prasa katrs process
Bind izdodas vai neizdodas pēc šī trijnieka, tāpēc divi dēmoni saduras tikai tad, kad sakrīt visas trīs daļas. Tāpēc vietne uz TCP 443 neierobežoti pastāv līdzās OpenVPN klausītājam uz UDP 443, un tāpēc viena no tiem pārvietošana uz otru vietējo adresi tajā pašā hostā arī beidz strīdu. Lasiet dzīvos klausītājus, nevis failus, kuriem tie bija jāizveido, jo novecojis include vai aizmirsts unit fails pārdzīvo jūsu atcerēto labojumu.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Palaidiet ss -lntup kā root un izlasiet katru rindu, kurā minēts 443, tostarp IPv6 ierakstus. Parasti universālais v6 klausītājs pieņem arī v4 trafiku, un tā aizmirsts klausītājs notur portu aizņemtu pēc tam, kad esat nomainījis failu, kuru uzskatījāt par atbildīgo. Ja procesa nosaukums jūs pārsteidz, sašauriniet izvadi ar ss -lntup 'sport = :443', pirms kaut ko aiztiekat.
Pārslēdziet tuneli uz UDP, kad tīkls to atļauj
UDP klausītājs pilnībā apiet sadursmi un parasti ir īsākais labojums, jo neviena ligzda netiek dalīta un ceļā neienāk neviens papildu produkts. Taču tas nav bez maksas. Daži klientu tīkli izmet UDP 443, nesūtot reset, tāpēc tunelis pārstāj veidoties, nevis neizdodas bind, un lietotājs ziņo, ka VPN ir izslēgts, bez kļūdas, ko izlasīt. UDP klausītājs arī pārdzīvo tīmekļa slāņa restartu, un tas ir svarīgi mašīnā, kuras vietne tiek bieži pārpublicēta. Pārbaudiet no tīkla, kurā sēž lietotāji, jo čaula uz servera tikai pierāda, ka serveris sasniedz pats sevi.
Mainiet transportu servera konfigurācijā un klienta profilā vienlaikus. Profils, kas joprojām prasa TCP, griezīsies atkārtotu savienojumu ciklos pret klausītāju, kuram ir tikai UDP, un tas izskatās kā tīkla kļūme, līdz salīdzināsiet abus failus.
Ļaujiet VPN procesam pārvaldīt TCP 443 un pārsūtiet pārējo
Community OpenVPN TCP servera režīmā nolasa ienākošā savienojuma pirmos baitus un pārsūta visu, kas nav tā paša protokols, uz HTTPS aizmuguri, un tam ir paredzēta direktīva port-share. Aizmugure ir parasts tīmekļa serveris ar ieslēgtu TLS, šajā direktīvā nosaukts ar hostu un portu, nevis ar URL.
port-share 10.0.0.5 8080
Mašīnā, kur vietnei ir otra privātā adrese, šī rinda sūta ne-VPN trafiku uz 10.0.0.5:8080, tāpēc HTTPS virtuālajam hostam jābūt tur piesaistītam, un ugunsmūrim jāatļauj vietējais lēciens. Tīmekļa serverim pašam jāpabeidz TLS, jo ienākošie baiti ir pārlūka sākotnējā rokasspiediena dati un nekas pa vidu tos nav atšifrējis. Vērsiet direktīvu uz vienkāršu HTTP klausītāju, un pārlūks saņems nederīgas metodes kļūdu, kas tiek lasīta kā salauzta vietne, nevis kā nepareizi ievietota aizmugure. Direktīva pastāv tikai TCP servera režīmā, un UDP klausītājam nav plūsmas, ko pārbaudīt.
Tā kā VPN process pieņem katru savienojumu, tīmekļa lietojumprogramma redz pārsūtīto pieprasījumu nākam no vienas no paša hosta adresēm, nevis no apmeklētāja. Viss, kam vajadzīga īstā klienta adrese, ir atkarīgs no PROXY protokola atbalsta aizmugurē vai no priekšgala, kas to pievieno. Aizmugures pārvietošana uz citu vietējo adresi neatgriež apmeklētāja adresi; tā tikai maina, kuru no hosta adresēm vietne ieraksta. Ierakstiet šo ierobežojumu izvietošanas piezīmēs, pirms analītikas pārskats izvirza jautājumu.
Apgrieztais starpniekserveris ir nepareizs rīks; ceturtā slāņa maršrutētājs nav
HTTP apgrieztais starpniekserveris pabeidz TLS, lai varētu lasīt pieprasījumus, kas nozīmē, ka tas nevar izlaist OpenVPN plūsmu neskartu. Ceturtā slāņa maršrutētājs, kas pārsūta pēc SNI vai pirmā paketa pārbaudes, var stāvēt abu priekšā, ja vien tas nepārtrauc sesiju, no kuras VPN ir atkarīgs. Abas ierīces diagrammā izskatās līdzīgi un pie ligzdas uzvedas pilnīgi citādi.
Komerciālais Access Server nāk ar saviem porta dalīšanas iestatījumiem, un tie neatbilst kopienas direktīvai viens pret vienu. Nosakiet produktu un versiju, pirms pielāgojat rokasgrāmatu, kas rakstīta otram. Nokopēts iestatījums, kas tiek klusi ignorēts, ir sliktāks par neiestatītu, jo klausītāju saraksts pēc tam joprojām izskatās ticams.
Pārbaudiet vietni un tuneli kā divus atsevišķus ceļus
Ielādējiet vietni un pievienojiet tuneli, pēc tam vēlreiz izlasiet klausītāju sarakstu, lai redzētu, kurš process tagad pārvalda 443. Ielādēta lapa neko nepierāda par VPN, un pievienots tunelis neko nepierāda par vietni, lai gan abi izmanto to pašu numuru. Trīs zemāk esošās komandas pārbauda kopīgo ligzdu, tīmekļa ceļu un VPN pakalpojumu šajā secībā.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Salīdziniet klienta adresi aizmugures piekļuves žurnālā ar to pašu VPN žurnālā tajā pašā brīdī. Ja vietne ieraksta katru apmeklētāju kā pašu hostu, pārsūtīšana darbojas, bet adreses apstrāde ne. Ja abi žurnāli klusē, priekšgals nekad nenodeva savienojumu. Jebkurā gadījumā klausītāju saraksts nosaka, kas pieņem ligzdu, un tas ir fakts, kas jāapstiprina pirms vēl viena faila maiņas.
Atstājiet šo klausītāju karti pie konfigurācijas, lai nākamais cilvēks, kas aiztiek 443, zinātu, kurš process pieņem un kur aizgāja otrs protokols. Apstipriniet īpašumtiesības pēc izmaiņām, nevis paļaujieties uz to, ko labojumam bija jādara.