OpenVPN i HTTPS na portu 443: kome pripada slušalac?

Dvije usluge mogu obje odgovarati na portu 443 a da se nikada ne natječu, jer se slušalac određuje po transportu, adresi i portu zajedno, a ne samo po broju. Stavite web server i OpenVPN na jednu mašinu, i jedino pitanje koje vrijedi prvo odgovoriti je koji socket svaki proces traži od kernela. Zapišite taj spisak prije nego uredite konfiguraciju, i većina grešaka „adresa je već u upotrebi“ objasnit će se sama. Sve poslije spiska je izbor između UDP slušaoca, zajedničkog TCP socketa ili prednjeg dijela koji usmjerava po protokolu.

Počnite sa socketom koji svaki proces traži

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šaocem na UDP 443, i zato premještanje jednog od njih na drugu lokalnu adresu na istom hostu također završava raspravu. Čitajte žive slušaoce, 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.

Pokrenite ss -lntup kao root i pročitajte svaki red koji spominje 443, uključujući IPv6 unose. Divlji v6 slušalac obično prihvata i v4 saobraćaj, i tako slušalac 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 šta dirnete.

Prebacite tunel na UDP kada mreža to dopušta

UDP slušalac potpuno zaobilazi sudar i obično je najkraća popravka, jer se nijedan socket ne dijeli i nijedan dodatni proizvod se ne pridružuje putu. Ali nije besplatno. Neke klijentske mreže odbacuju UDP 443 bez slanja reset-a, pa tunel prestaje da se uspostavlja umjesto da ne uspije bind, i korisnik prijavljuje VPN kao neispravan bez greške za čitanje. UDP slušalac također nadživi restart web sloja, što se računa na mašini čija se stranica često ponovo objavljuje. Testirajte iz mreže u kojoj sjede korisnici, jer shell na serveru dokazuje samo da server može doći do sebe.

Promijenite transport u konfiguraciji servera i u profilu klijenta zajedno. Profil koji još traži TCP kružiće kroz ponovna povezivanja prema slušaocu samo na UDP, i to izgleda kao mrežni kvar dok ne uporedite 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 server sa uključenim TLS-om, imenovan hostom i portom u toj direktivi, a ne URL-om.

port-share 10.0.0.5 8080

Na mašini gdje stranica drži drugu privatnu adresu, taj red šalje ne-VPN saobraćaj na 10.0.0.5:8080, pa HTTPS virtuelni host mora biti bindan tamo i firewall mora dopustiti lokalni skok. Web server mora sam završiti TLS, jer bajtovi koji dolaze su originalni handshake preglednika i ništa između ih nije dešifrovalo. Usmjerite direktivu na običan HTTP slušalac i preglednik dobija grešku nevažeće metode, koja se čita kao pokvarena stranica, a ne kao pogrešno postavljen backend. Direktiva postoji samo u TCP server modu, a UDP slušalac nema tok za pregled.

Pošto VPN proces prihvata svaku vezu, web aplikacija vidi proslijeđeni zahtjev kako dolazi s jedne od vlastitih adresa hosta umjesto od posjetioca. Sve što treba pravu adresu klijenta zavisi od podrške za PROXY protokol u backendu ili od prednjeg dijela koji je dodaje. Premještanje backenda na drugu lokalnu adresu ne vraća adresu posjetioca; 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 je pogrešan alat; usmjerivač četvrtog sloja nije

HTTP obrnuti proxy završava TLS da 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 oba, pod uslovom da ne završava sesiju o kojoj VPN zavisi. Dva uređaja izgledaju slično na dijagramu, a ponašaju se potpuno različito na socketu.

Komercijalni Access Server isporučuje vlastite postavke dijeljenja porta, i one se ne preslikavaju jedan-na-jedan na community direktivu. Identifikujte proizvod i verziju prije nego prilagodite vodič napisan za onaj drugi. Kopirana postavka koja se tiho ignoriše gora je od nikakve postavke, jer spisak slušalaca nakon toga još uvijek izgleda uvjerljivo.

Testirajte web stranicu i tunel kao dva odvojena puta

Učitajte stranicu i povežite tunel, zatim ponovo pročitajte spisak slušalaca 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 komande 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

Uporedite adresu klijenta u pristupnom logu backenda sa onom u VPN logu za isti trenutak. Ako stranica bilježi svakog posjetioca kao sam host, prosljeđivanje radi, a rukovanje adresom ne. Ako oba loga ćute, prednji dio nikada nije predao vezu. U svakom slučaju spisak slušalaca odlučuje ko prihvata socket, i to je činjenica koju treba potvrditi prije nego promijenite još jednu datoteku.

Ostavite tu mapu slušalaca pored konfiguracije da sljedeća osoba koja dirne 443 zna koji proces prihvata i gdje je otišao drugi protokol. Potvrdite vlasništvo nakon izmjene umjesto da vjerujete onome što je izmjena trebala učiniti.