Jedan OpenVPN port, tri usluge: zašto su unutarnji portovi važni

Jedna SSH sesija, jedna web aplikacija i jedno traženje imena mogu dijeliti jednu VPN vezu bez borbe za portove. Klijent gradi jedan šifrirani tok prema pristupniku i svaki razgovor aplikacije putuje unutar njega. Izvana su vidljivi samo vlastiti transport i port tunela. Iznutra svaka usluga zadržava svoj port i dalje joj treba vlastito dopuštenje.

Što nosi vanjski tok i što skriva

Klijent umotava svaki paket u transport tunela prije nego što napusti stroj. Taj vanjski tok ima jedan odredišni port, fiksiran pri konfiguraciji VPN-a. Unutar omotača svaki izvorni paket zadržava adresu i port usluge kojoj je namijenjen. Pristupnik skida omotač i usmjerava prema unutarnjem zaglavlju, pa odredište vidi običnog klijenta koji dolazi iz mreže.

Snimka na WAN sučelju zato pokazuje jedan razgovor, a ne tri. Unutarnji portovi pojavljuju se tek nakon dekapsulacije. Zato jedan otvor na vatrozidu može nositi SSH, HTTPS i DNS istovremeno.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

Dokumentacija za TUN/TAP pokriva prijelaz u kojem rutirana TUN naprava prenosi IP pakete između kernela i korisničkog procesa. Taj prijelaz čini unutarnje zaglavlje vidljivim rutiranju i vatrozidnom kodu pristupnika. Također objašnjava zašto vanjski port ne govori ništa o tome koje su usluge dopuštene.

NAT prosljeđivanje pripada slušatelju, ne aplikacijama

Samostalno hostiran pristupnik iza IPv4 NAT-a treba jedno ulazno prevođenje: javna adresa i port mapirani na VPN slušatelja. Nikakvo pravilo nije potrebno za SSH, HTTPS ili DNS samo zato što korisnici tunela do njih dolaze. Objavljivanje tih portova izložilo bi usluge koje tunel već štiti. Pravilo prosljeđivanja opisuje dostupnost slušatelja, a ne dopuštenje za bilo što unutra.

Vrijedi i obrnuto. Otvaranje porta tunela ne izlaže ništa drugo, pa usluga dostupna samo kroz tunel zadržava svoju javnu površinu zatvorenom. Ta podjela obično je razlog zašto se usluga uopće drži privatnom.

Unutarnja politika mjesto je gdje se pristup zapravo odlučuje

Enkripcija štiti put; ona ne odobrava odredište. Rute klijenta biraju koji prefiksi ulaze u tunel, politika prosljeđivanja pristupnika odlučuje smiju li paketi izaći iz njega, a vatrozid odredišta plus prijava odlučuju hoće li usluga odgovoriti. DNS je najjasniji slučaj: nošenje upita ne čini da resolver prihvati ih iz vašeg klijentskog skupa. Svaki sloj može neovisno reći ne.

Testirajte svaku uslugu zasebno kroz tunel. Uspješno traženje ne govori ništa o web portu, a uspješan web zahtjev ne govori ništa o SSH-u.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Kada je tunel podignut i sve ne uspijeva, prvo pročitajte rutnu tablicu klijenta. Kada jedna usluga ne uspijeva dok ostale rade, kvar je na tom odredištu. Ta dva zapažanja upućuju na različite vlasnike, a njihovo miješanje troši vrijeme.

WireGuard povlači istu liniju

WireGuard naziva svoj vanjski slušatelj ListenPort, a unutarnja aplikacija i dalje koristi koji god port usluge joj treba. AllowedIPs je skup rutiranih prefiksa, a ne popis dopuštenih portova usluga. Čitanje toga kao popisa dopuštenih portova stvara pravila koja se ne poklapaju s onim što tunel radi. Imenovanje je drugačije; slojevitost nije.

Dopustite uslugu u politici lokalnog ulaza kada radi na samoj krajnjoj točki, ili u politici prosljeđivanja kada se nalazi iza te točke. Ta razlika odlučuje koji skup pravila vidi paket.

Opći oblik je jedan vanjski transport s mnogo unutarnjih razgovora. Proizvodi kojima treba nekoliko vanjskih razmjena ili drukčiji IP protokol podsjećaju da obrazac jednog javnog porta opisuje ovaj dizajn, a ne svaki VPN.