Jedan OpenVPN port, tri usluge: zašto su unutrašnji 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 gejtveju 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 vlastita dozvola.

Šta nosi vanjski tok i šta skriva

Klijent umotava svaki paket u transport tunela prije nego što napusti mašinu. 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. Gejtvej skida omotač i usmjerava prema unutrašnjem zaglavlju, pa odredište vidi običnog klijenta koji dolazi iz mreže.

Snimak na WAN interfejsu zato pokazuje jedan razgovor, a ne tri. Unutrašnji portovi se pojavljuju 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 unutrašnje zaglavlje vidljivim rutiranju i vatrozidnom kodu gejtveja. Također objašnjava zašto vanjski port ne govori ništa o tome koje su usluge dopuštene.

NAT prosljeđivanje pripada slušaocu, ne aplikacijama

Samostalno hostovan gejtvej iza IPv4 NAT-a treba jedno ulazno prevođenje: javna adresa i port mapirani na VPN slušaoca. 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šaoca, a ne dozvolu za bilo šta 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 je obično razlog zašto se usluga uopće drži privatnom.

Unutrašnja politika je mjesto gdje se pristup zaista odlučuje

Enkripcija štiti put; ona ne odobrava odredište. Rute klijenta biraju koji prefiksi ulaze u tunel, politika prosljeđivanja gejtveja 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 pula. Svaki sloj može nezavisno 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 tabelu 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šalac ListenPort, a unutrašnja 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šti oblik je jedan vanjski transport s mnogo unutrašnjih 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.