Dva DNS imena, jedan OpenVPN port: šta zapravo bira
Dva imena hosta koja pokazuju na jednu adresu ipak stižu do jednog slušaoca. Samo polje koje klijent pošalje može izabrati backend, a standardni OpenVPN ga ne šalje.
Dva A zapisa, jedna adresa, jedan demon: koje god ime korisnik ukuca, paket koji stigne je identičan, a proces vezan na port 1194 nema čime razlikovati ta dva. To nije pogrešna konfiguracija koja čeka popravku; to je granica onoga što pretraga po imenu može izraziti. Sve što bira između dvije OpenVPN instance mora biti vrijednost koju klijent stavlja u vezu i koju frontend može pročitati natrag, a standardni OpenVPN klijent ne stavlja takvu vrijednost u otvorenom obliku. Ono što slijedi je gdje vas to ostavlja i koji rasporedi stvarno razdvajaju saobraćaj.
Počnite od onoga što resolver vraća
Klijent traži vpn-a.example i dobija adresu; ta adresa plus port je sve prema čemu se spaja. Ime se troši lokalno, tokom pretrage, i nikada ne postaje polje na mreži, pa slušalac na drugoj strani ne može vidjeti koja je oznaka korištena. Usmjerite vpn-a.example i vpn-b.example na jedan host i obje pretrage daju istu destinaciju, zbog čega demon upija obje veze u jednu instancu bez registriranja razlike. Profili zasnovani na adresi ponašaju se isto kao oni zasnovani na imenu, iz istog razloga.
To također zatvara porodicu primamljivih zaobilaznih rješenja: dodatni aliasi, biranje certifikata po imenu na jednom socketu ili firewall pravilo vezano za traženo ime. Nijedno od njih ne može djelovati na informaciju koja je već odbačena prije nego što je prvi paket napustio klijent. Ako dva servera moraju ostati odvojena, podjela mora putovati sa samom vezom, što znači adresa, port ili polje korisnog tereta koje protokol definira.
Jedini selektor koji se računa putuje unutar paketa
HTTP to rješava zaglavljem Host, a TLS proširenjem za ime servera u ClientHello, i tako jedna adresa služi mnoge stranice iza jednog slušaoca. Oba rade jer žičani protokol nosi zahtjev za određenom uslugom. Relevantna činjenica o OpenVPN-u je da nijedno od tih polja nije prisutno na sloju koji posrednički uređaj pregleda.
U standardnom rasporedu TLS rukovanje koje štiti kontrolni kanal odvija se nakon uspostavljanja vanjske sesije i prenosi se unutar nje, pa slušalac koji tu sesiju nije prekinuo vidi neproziran tok. Još uvijek može reći da je to OpenVPN, jer su opkod i uokvirenje u početnim bajtovima prepoznatljivi, ali ime servera, ako postoji, stoji u šifriranom dijelu. Dizajn koji očekuje da pročita virtualni host iz vanjskog paketa čita polje koje protokol nikada tamo ne piše. To dolazi iz načina na koji je tunel izgrađen, a ne iz praznine koju bi pametnije podudaranje uzorka moglo zatvoriti.
Gdje razdjelnik protokola staje
Multiplekser kakav dokumentira sslh projekat sluša na jednom portu, pregleda početne bajtove i predaje vezu onom backendu koji govori prepoznati protokol. To je stvarna vrijednost kada jedan port mora služiti SSH, HTTPS i OpenVPN zajedno.
sslh drži zasebnu sondu za svaki protokol, a njegova TLS sonda može izvući ime servera ili ALPN vrijednost iz pravog ClientHello-a. Prepoznavanje standardnog OpenVPN-a drugačija je klasifikacija od čitanja TLS proširenja i to dvoje se ne sastavlja, jer klijent koji nikada ne pošalje ClientHello na slušajući socket ostavlja sondu bez ičega za čitanje. Zato pravilo koje odgovara OpenVPN-u daje odgovor “ovo je OpenVPN klijent” i ne ide dalje. Dva OpenVPN backenda iza tog pravila su nerazlučiva, frontend nema osnovu za izbor i svaka sesija završi na istom mjestu. Multipleksiranje dijeli jedan port između različitih usluga; ono ne obavlja virtualni hosting unutar jedne usluge.
Rasporedi koji zaista razdvajaju dva servera
Najjeftinija poštena podjela je druga javna adresa, jedna po instanci, a postojeći profili već nose ono što treba jer pokazuju na različite adrese. Sljedeća je drugi port na istoj adresi, što ne košta ništa osim broja u svakom profilu. TCP i UDP drže odvojene tablice portova, pa su 1194/tcp i 1194/udp nepovezani socketi i po jedan od svakog može postojati na istom hostu; to je transportna podjela, a ne usmjeravanje po imenu, i često se s njim brka. Obje opcije prolaze firewall pregled, jer pravilo odgovara nečemu što paket zaista sadrži.
Ako granica koja vam treba ide između grupa korisnika umjesto između dvije implementacije, jedna instanca s različitim konfiguracijama klijenata, vlastitim rukovanjem certifikatima i izričitom politikom pristupa može je pokriti. To kupuje politiku unutar servera, a ne izolaciju između servera, i to su različiti zahtjevi. Izolacija koja mora izdržati pod kompromitacijom još uvijek treba adresu ili firewall ivicu.
TLS terminator postavljen ispred OpenVPN-a može izložiti pravo ime servera sposobnom frontendu, ali samo kada je i klijentska strana konfigurirana za taj dodatni sloj. Postojeći profili ne stječu to ponašanje time što se usmjere na istu adresu.
Dokažite selektor prije nego što gradite
Imenujte polje koje će identificirati backend, pa potvrdite da ga klijent zaista šalje; ako je odgovor adresa, plan stoji, a ako je ime servera unutar rukovanja koje nikada ne stigne do slušaoca, nikakav rad na DNS-u ga neće spasiti. Tri komande brzo rješavaju pitanje slušajuće strane.
ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager
Linija openssl daje certifikat samo tamo gdje nešto na toj adresi prekida TLS; protiv standardnog OpenVPN slušaoca ona zastane ili padne, što je samo po sebi odgovor o tome šta vanjski sloj otkriva. Linija journal, pročitana na svakom backendu, pokazuje koja je instanca prihvatila sesiju. Frontend logovi bilježe šta je klasificirano, a nikada šta je bilo namjeravano, pa backend ostaje jedini autoritet o tome gdje je korisnik završio.
Završite s dva profila namijenjena različitim serverima, povežite ih jedan po jedan i zabilježite backend log za svaki. Ako se obje sesije pojave u istom journalu, selektor nedostaje, a nije pogrešno konfiguriran, i popravka je adresa ili port koji klijent može ciljati. Uređivanje routing pravila neće pomoći, jer pravilu nikada nije dato ništa po čemu bi usmjeravalo. Kad podjela postane stvarna, zapišite je uz profile da sljedeća osoba ne doda drugi alias i ne očekuje da će on obaviti posao.