OpenVPN i HTTPS na portu 443: čiji je slušalac?

Dve usluge mogu obe odgovarati na portu 443 a da se nikada ne takmiče, jer se slušalac određuje prema transportu, adresi i portu zajedno, a ne samo prema broju. Postavite veb server i OpenVPN na istu mašinu, i jedino pitanje koje vredi prvo odgovoriti jeste koji priključak svaki proces traži od kernela. Zapišite taj spisak pre nego što uredite konfiguraciju, i većina grešaka „adresa je već u upotrebi“ objasniće se sama. Sve posle spiska je izbor između UDP slušaoca, zajedničkog TCP priključka ili prednjeg dela koji usmerava prema protokolu.

Pođite od priključka koji traži svaki proces

Bind uspeva ili ne uspeva prema toj trojci, pa se dva demona sudaraju samo kada se sva tri dela poklope. Zato veb stranica na TCP 443 neograničeno postoji uz OpenVPN slušalac na UDP 443, i zato premeštanje jednog od njih na drugu lokalnu adresu na istom hostu takođe završava raspravu. Čitajte žive slušaoce, a ne datoteke koje su trebale da ih stvore, jer zastareo include ili zaboravljena unit datoteka nadživi izmenu koje se sećate.

Pokrenite ss -lntup kao root i pročitajte svaki red koji pominje 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 promenite datoteku koju ste smatrali odgovornom. Ako vas ime procesa iznenadi, suzite izlaz pomoću ss -lntup 'sport = :443' pre nego što bilo šta dodirnete.

Prebacite tunel na UDP kada mreža to dozvoli

UDP slušalac potpuno zaobilazi sudar i obično je najkraća popravka, jer se nijedan priključak ne deli i nijedan dodatni proizvod ne ulazi na put. Ali to nije besplatno. Neke klijentske mreže odbacuju UDP 443 bez slanja reset-a, pa tunel prestaje da se uspostavlja umesto da ne uspe bind, i korisnik prijavljuje da VPN ne radi bez ikakve greške za čitanje. UDP slušalac takođe nadživi restart veb sloja, što se računa na mašini čiji se sajt često ponovo objavljuje. Testirajte iz mreže u kojoj sede korisnici, jer ljuska na serveru dokazuje samo da server doseže sebe.

Promenite 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 dve datoteke.

Neka VPN proces poseduje TCP 443, a ostalo prosledite

Community OpenVPN u TCP server režimu čita prve bajtove dolazne veze i prosleđuje sve što nije njegov protokol na HTTPS backend, i tome služi direktiva port-share. Backend je običan veb 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 gde sajt ima drugu privatnu adresu, taj red šalje ne-VPN saobraćaj na 10.0.0.5:8080, pa HTTPS virtuelni host mora biti vezan tamo i vatrozid mora dozvoliti lokalni skok. Veb server mora sam završiti TLS, jer bajtovi koji dolaze su originalni handshake pregledača i ništa između ih nije dešifrovalo. Usmerite direktivu na običan HTTP slušalac i pregledač dobija grešku nevažeće metode, koja se čita kao pokvaren sajt, a ne kao pogrešno postavljen backend. Direktiva postoji samo u TCP server režimu, a UDP slušalac nema tok za pregled.

Pošto VPN proces prihvata svaku vezu, veb aplikacija vidi prosleđeni zahtev kako dolazi sa jedne od sopstvenih adresa hosta umesto od posetioca. Sve što treba pravu adresu klijenta zavisi od podrške za PROXY protokol u backendu ili od prednjeg dela koji je dodaje. Premeštanje backenda na drugu lokalnu adresu ne vraća adresu posetioca; ono samo menja koju od adresa hosta sajt beleži. Zapišite to ograničenje u beleške o postavljanju pre nego što izveštaj analitike pokrene pitanje.

Obrnuti proksi je pogrešan alat; usmerivač četvrtog sloja nije

HTTP obrnuti proksi završava TLS da bi mogao da čita zahteve, što znači da ne može propustiti OpenVPN tok netaknut. Usmerivač četvrtog sloja koji prosleđuje prema SNI ili prema pregledu prvog paketa može stajati ispred oba, pod uslovom da ne završava sesiju od koje VPN zavisi. Dva uređaja izgledaju slično na dijagramu, a ponašaju se potpuno različito na priključku.

Komercijalni Access Server isporučuje sopstvena podešavanja deljenja porta, i ona se ne preslikavaju jedan-na-jedan na direktivu zajednice. Identifikujte proizvod i verziju pre nego što prilagodite vodič napisan za onaj drugi. Kopirano podešavanje koje se tiho ignoriše gore je od nikakvog podešavanja, jer spisak slušalaca posle toga i dalje izgleda uverljivo.

Testirajte sajt i tunel kao dva odvojena puta

Učitajte sajt i povežite tunel, zatim ponovo pročitajte spisak slušalaca da vidite koji proces sada poseduje 443. Stranica koja se učita ne dokazuje ništa o VPN-u, a tunel koji se poveže ne dokazuje ništa o sajtu, iako oba koriste isti broj. Tri naredbe ispod proveravaju zajednički priključak, veb 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 sajt beleži svakog posetioca kao sam host, prosleđivanje radi, a rukovanje adresom ne. Ako oba loga ćute, prednji deo nikada nije predao vezu. U svakom slučaju spisak slušalaca odlučuje ko prihvata priključak, i to je činjenica koju treba potvrditi pre nego što promenite još jednu datoteku.

Ostavite tu mapu slušalaca pored konfiguracije da sledeća osoba koja dodirne 443 zna koji proces prihvata i kuda je otišao drugi protokol. Potvrdite vlasništvo nakon izmene umesto da verujete onome što je izmena trebala da uradi.