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

Jedna SSH sesija, jedna veb aplikacija i jedna pretraga imena mogu deliti jednu VPN vezu bez borbe za portove. Klijent gradi jedan šifrovani tok ka gejtveju, i svaki razgovor aplikacije putuje unutar njega. Spolja su vidljivi samo transport i port samog tunela. Unutra, svaka usluga zadržava svoj port i dalje joj treba sopstvena dozvola.

Šta spoljni tok nosi i šta skriva

Klijent umotava svaki paket u transport tunela pre nego što napusti mašinu. Taj spoljni tok ima jedan odredišni port, fiksiran kada je VPN konfigurisan. Unutar omotača, svaki originalni paket zadržava adresu i port usluge kojoj je namenjen. Gejtvej skida omotač i rutira po 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 posle dekapsulacije. Zato jedan otvor na zaštitnom zidu 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 TUN/TAP opisuje prelaz u kome rutirana TUN naprava prenosi IP pakete između jezgra i procesa u korisničkom prostoru. Taj prelaz čini unutrašnje zaglavlje vidljivim za rutiranje i kod zaštitnog zida gejtveja. Takođe objašnjava zašto spoljni port ne govori ništa o tome koje su usluge dozvoljene.

NAT prosleđivanje pripada slušaocu, ne aplikacijama

Samostalno hostovan gejtvej iza IPv4 NAT-a treba jedno ulazno prevođenje: javna adresa i port se mapiraju na VPN slušalac. 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 prosleđivanja opisuje dostupnost slušaoca, a ne dozvolu za bilo šta unutra.

Važi i obrnuto. Otvaranje porta tunela ne izlaže ništa drugo, pa usluga dostupna samo kroz tunel drži svoju javnu površinu zatvorenom. To razdvajanje je obično razlog da usluga ostane privatna.

Unutrašnja politika je mesto gde se pristup zaista odlučuje

Šifrovanje štiti putanju; ono ne ovlašćuje odredište. Rute klijenta biraju koji prefiksi ulaze u tunel, politika prosleđivanja gejtveja odlučuje da li paketi mogu da ga napuste, a zaštitni zid i prijava odredišta odlučuju da li će usluga odgovoriti. DNS je najjasniji slučaj: nošenje upita ne čini da ih risolver prihvati iz vašeg klijentskog pula. Svaki sloj može reći ne nezavisno.

Testirajte svaku uslugu zasebno kroz tunel. Uspešna pretraga ne govori ništa o veb portu, a uspešan veb zahtev 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 aktivan a sve ne uspeva, prvo pročitajte tabelu ruta klijenta. Kada jedna usluga ne uspeva dok ostale rade, kvar je na tom odredištu. Ta dva zapažanja ukazuju na različite vlasnike, a njihovo mešanje troši vreme.

WireGuard povlači istu liniju

WireGuard svoj spoljni slušalac naziva ListenPort, a unutrašnja aplikacija i dalje koristi port usluge koji joj je potreban. AllowedIPs je skup rutiranih prefiksa, a ne lista dozvoljenih portova usluga. Čitanje kao liste dozvoljenih portova daje pravila koja se ne poklapaju sa onim što tunel radi. Imenovanje je drugačije; slojevitost nije.

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

Opšti oblik je jedan spoljni transport sa mnogo unutrašnjih razgovora. Proizvodi kojima treba nekoliko spoljnih razmena, ili drugačiji IP protokol, podsećaju da obrazac jednog javnog porta opisuje ovaj dizajn, a ne svaki VPN.