Ena vrata OpenVPN, tri storitve: zakaj so notranja vrata pomembna

Ena seja SSH, ena spletna aplikacija in eno iskanje imena si lahko delijo eno povezavo VPN brez boja za vrata. Odjemalec zgradi en šifriran tok do prehoda, in vsak pogovor aplikacije potuje znotraj njega. Zunaj sta vidna le lastni promet in vrata tunela. Znotraj vsaka storitev obdrži svoja vrata in še vedno potrebuje svoje dovoljenje.

Kaj nosi zunanji tok in kaj skriva

Odjemalec ovije vsak paket v promet tunela, preden zapusti stroj. Ta zunanji tok ima ena ciljna vrata, določena ob konfiguraciji VPN. Znotraj ovoja vsak izvirni paket obdrži naslov in vrata storitve, ki jo cilja. Prehod odstrani ovoj in usmerja po notranji glavi, zato cilj vidi običajnega odjemalca, ki prihaja iz omrežja.

Zajem na vmesniku WAN torej pokaže en pogovor, ne treh. Notranja vrata se pokažejo šele po dekapsulaciji. Zato lahko ena odprtina požarnega zidu hkrati nosi SSH, HTTPS in DNS.

# 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 predajo, pri kateri usmerjena naprava TUN predaja pakete IP med jedrom in procesom v uporabniškem prostoru. Ta predaja naredi notranjo glavo vidno kodi za usmerjanje in požarni zid prehoda. Pojasni tudi, zakaj zunanja vrata ne povedo nič o tem, katere storitve so dovoljene.

Posredovanje NAT pripada poslušalcu, ne aplikacijam

Samostojno gostovan prehod za NAT IPv4 potrebuje en prevod na vhodu: javni naslov in vrata se preslikata na poslušalec VPN. Nobeno pravilo ni potrebno za SSH, HTTPS ali DNS samo zato, ker uporabniki tunela dosežejo te storitve. Objava teh vrat bi razkrila storitve, ki jih tunel že ščiti. Pravilo posredovanja opisuje dosegljivost poslušalca, ne dovoljenja za kar koli znotraj.

Velja tudi obratno. Odprtje vrat tunela ne razkrije ničesar drugega, zato storitev, dosegljiva le skozi tunel, ohrani svojo javno površino zaprto. Ta ločitev je običajno razlog, da storitev ostane zasebna.

Notranja politika je kraj, kjer se dostop dejansko odloča

Šifriranje ščiti pot; ne pooblašča cilja. Poti odjemalca izberejo, kateri predponi vstopijo v tunel, politika posredovanja prehoda odloči, ali lahko paketi zapustijo tunel, požarni zid in prijava cilja pa odločita, ali bo storitev odgovorila. DNS je najjasnejši primer: prenašanje poizvedb ne naredi, da bi jih razreševalnik sprejel iz vašega nabora odjemalcev. Vsak sloj lahko reče ne neodvisno.

Preizkusite vsako storitev posebej skozi tunel. Uspešno iskanje ne pove nič o spletnih vratih, uspešna spletna zahteva pa ne pove nič o SSH.

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

Ko je tunel aktiven in vse odpove, najprej preberite usmerjevalno tabelo odjemalca. Ko ena storitev odpove, druge pa delujejo, je napaka na tem cilju. Ti dve opažanji kažeta na različne lastnike, njuno mešanje pa zapravlja čas.

WireGuard potegne isto črto

WireGuard svoj zunanji poslušalec imenuje ListenPort, notranja aplikacija pa še vedno uporablja vrata storitve, ki jih potrebuje. AllowedIPs je niz usmerjenih predpon, ne seznam dovoljenih vrat storitev. Branje kot seznama dovoljenih vrat ustvari pravila, ki se ne ujemajo s tem, kar počne tunel. Poimenovanje je drugačno; plastenje ni.

Dovolite storitev v politiki lokalnega vhoda, ko teče na sami končni točki, ali v politiki posredovanja, ko je za to končno točko. Ta razlika odloči, kateri nabor pravil vidi paket.

Splošna oblika je en zunanji promet z mnogimi notranjimi pogovori. Izdelki, ki potrebujejo več zunanjih izmenjav ali drug protokol IP, spomnijo, da vzorec enih javnih vrat opisuje to zasnovo in ne vsakega VPN.