OpenVPN i HTTPS na portu 443: kome pripada slušatelj?
TCP i UDP 443 odvojeni su soketi. Dijeljenje jednog TCP slušatelja zahtijeva vlasnika, a dijeljenje porta OpenVPN-a uski je dogovor, ne trik s proxyjem.
Dvije usluge mogu obje odgovarati na portu 443 bez ikakvog natjecanja, jer se slušatelj određuje po transportu, adresi i portu zajedno, a ne samo po broju. Stavite web poslužitelj i OpenVPN na jedno računalo, i jedino pitanje koje vrijedi prvo odgovoriti jest koji socket svaki proces traži od kernela. Zapišite taj popis prije nego uredite konfiguraciju, i većina pogrešaka „adresa je već u upotrebi“ objasnit će se sama. Sve nakon popisa izbor je između UDP slušatelja, zajedničkog TCP socketa ili prednjeg dijela koji usmjerava po protokolu.
Počnite sa socketom koji traži svaki proces
Bind uspijeva ili ne uspijeva po toj trojci, pa se dva daemona sudaraju samo kada se sva tri dijela poklope. Zato web stranica na TCP 443 neograničeno koegzistira sa OpenVPN slušateljem na UDP 443, i zato premještanje jednoga od njih na drugu lokalnu adresu na istom hostu također završava raspravu. Čitajte žive slušatelje, a ne datoteke koje su ih trebale stvoriti, jer zastarjeli include ili zaboravljena unit datoteka nadživi izmjenu koju se sjećate da ste napravili.
| 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 |
Pokrenite ss -lntup kao root i pročitajte svaki redak koji spominje 443, uključujući IPv6 unose. Divlji v6 slušatelj obično prihvaća i v4 promet, i tako slušatelj koji ste zaboravili drži port zauzetim nakon što promijenite datoteku za koju ste mislili da je odgovorna. Ako vas ime procesa iznenadi, suzite izlaz pomoću ss -lntup 'sport = :443' prije nego bilo što dotaknete.
Prebacite tunel na UDP kada mreža to dopušta
UDP slušatelj potpuno zaobilazi sudar i obično je najkraća popravka, jer se nijedan socket ne dijeli i nijedan dodatni proizvod ne pridružuje putu. Ali nije besplatno. Neke klijentske mreže odbacuju UDP 443 bez slanja reset-a, pa tunel prestaje uspostavljati se umjesto da ne uspije bind, i korisnik prijavljuje VPN kao neispravan bez pogreške za čitanje. UDP slušatelj također nadživi ponovno pokretanje web sloja, što se računa na računalu čije se stranice često ponovno objavljuju. Testirajte iz mreže u kojoj sjede korisnici, jer ljuska na poslužitelju dokazuje samo da poslužitelj može doći do sebe.
Promijenite transport u konfiguraciji poslužitelja i u profilu klijenta zajedno. Profil koji još traži TCP kružit će kroz ponovna povezivanja prema slušatelju samo na UDP, i to izgleda kao mrežni kvar dok ne usporedite dvije datoteke.
Neka VPN proces posjeduje TCP 443, a ostalo proslijedite
Community OpenVPN u TCP server modu čita prve bajtove dolazne veze i prosljeđuje sve što nije njegov protokol na HTTPS backend, i tome služi direktiva port-share. Backend je običan web poslužitelj s uključenim TLS-om, imenovan hostom i portom u toj direktivi, a ne URL-om.
port-share 10.0.0.5 8080
Na računalu gdje stranica drži drugu privatnu adresu, taj redak šalje ne-VPN promet na 10.0.0.5:8080, pa HTTPS virtualni host mora biti bindan tamo i vatrozid mora dopustiti lokalni skok. Web poslužitelj mora sam završiti TLS, jer bajtovi koji dolaze originalni su handshake preglednika i ništa između ih nije dešifriralo. Usmjerite direktivu na običan HTTP slušatelj i preglednik dobiva pogrešku nevaljane metode, koja se čita kao pokvarena stranica, a ne kao pogrešno postavljen backend. Direktiva postoji samo u TCP server modu, a UDP slušatelj nema tok za pregled.
Budući da VPN proces prihvaća svaku vezu, web aplikacija vidi proslijeđeni zahtjev kako dolazi s jedne od vlastitih adresa hosta umjesto od posjetitelja. Sve što treba pravu adresu klijenta ovisi o podršci za PROXY protokol u backendu ili o prednjem dijelu koji je dodaje. Premještanje backenda na drugu lokalnu adresu ne vraća adresu posjetitelja; ono samo mijenja koju od adresa hosta stranica bilježi. Zapišite to ograničenje u bilješke o postavljanju prije nego izvještaj analitike pokrene pitanje.
Obrnuti proxy pogrešan je alat; usmjerivač četvrtog sloja nije
HTTP obrnuti proxy završava TLS kako bi mogao čitati zahtjeve, što znači da ne može propustiti OpenVPN tok netaknut. Usmjerivač četvrtog sloja koji prosljeđuje po SNI ili po pregledu prvog paketa može stajati ispred obaju, pod uvjetom da ne završava sesiju o kojoj VPN ovisi. Dva uređaja izgledaju slično na dijagramu, a ponašaju se posve različito na socketu.
Komercijalni Access Server isporučuje vlastite postavke dijeljenja porta, i one se ne preslikavaju jedan-na-jedan na community direktivu. Identificirajte proizvod i verziju prije nego prilagodite vodič napisan za onaj drugi. Kopirana postavka koja se tiho ignorira gora je od nikakve postavke, jer popis slušatelja nakon toga još uvijek izgleda uvjerljivo.
Testirajte web stranicu i tunel kao dva odvojena puta
Učitajte stranicu i povežite tunel, zatim ponovno pročitajte popis slušatelja da vidite koji proces sada posjeduje 443. Stranica koja se učita ne dokazuje ništa o VPN-u, a tunel koji se poveže ne dokazuje ništa o stranici, iako oboje koriste isti broj. Tri naredbe ispod provjeravaju zajednički socket, web put i VPN uslugu tim redom.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Usporedite adresu klijenta u pristupnom logu backenda s onom u VPN logu za isti trenutak. Ako stranica bilježi svakog posjetitelja kao sam host, prosljeđivanje radi, a rukovanje adresom ne. Ako oba loga šute, prednji dio nikada nije predao vezu. U svakom slučaju popis slušatelja odlučuje ko prihvaća socket, i to je činjenica koju treba potvrditi prije nego promijenite još jednu datoteku.
Ostavite tu kartu slušatelja pokraj konfiguracije da sljedeća osoba koja dotakne 443 zna koji proces prihvaća i kamo je otišao drugi protokol. Potvrdite vlasništvo nakon izmjene umjesto da vjerujete onome što je izmjena trebala učiniti.