Üks OpenVPN port, kolm teenust: miks seesmised pordid loevad

Üks SSH-seanss, üks veebirakendus ja üks nimepäring võivad jagada üht VPN-ühendust, ilma et nad portide pärast kakleksid. Klient ehitab lüüsini ühe krüpteeritud voolu ja iga rakenduse vestlus liigub selle sees. Väljast on nähtavad ainult tunnelile endale kuuluv transport ja port. Sees hoiab iga teenus oma porti ja vajab endiselt oma luba.

Mida välimine vool kannab ja mida see varjab

Klient mässib iga paketi tunnelitransporti enne, kui see masinast lahkub. Sellel välimisel voolul on üks sihtport, mis määrati VPN-i seadistamisel. Ümbrise sees hoiab iga algne pakett selle teenuse aadressi ja porti, mida see sihib. Lüüs eemaldab ümbrise ja suunab sisemise päise järgi, nii et sihtkoht näeb võrgust saabuvat tavalist klienti.

Seetõttu näitab WAN-liidese jäädvustus üht vestlust, mitte kolme. Sisemised pordid ilmuvad alles pärast dekapsuleerimist. Sellepärast saab üks tulemüüri ava kanda SSH-d, HTTPS-i ja DNS-i korraga.

# 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

TUN/TAP-i dokumentatsioon käsitleb üleandmist, mille käigus marsruuditud TUN-seade annab IP-pakette kerneli ja kasutajaruumi protsessi vahel edasi. Just see üleandmine teeb sisemise päise lüüsi marsruutimis- ja tulemüürikoodile nähtavaks. Samuti selgitab see, miks välimine port ei ütle midagi selle kohta, millised teenused on lubatud.

NAT-i edastus kuulub kuulajale, mitte rakendustele

IPv4 NAT-i taga isemajutatud lüüs vajab üht sissetulevat tõlget: avalik aadress ja port kaardistatakse VPN-i kuulajale. SSH, HTTPS või DNS jaoks pole reeglit vaja ainult seetõttu, et tunnelikasutajad nendeni jõuavad. Nende portide avalikustamine paljastaks teenuseid, mida tunnel juba kaitseb. Edastusreegel kirjeldab kuulaja kättesaadavust, mitte luba millegi jaoks sees.

Vastupidine kehtib samuti. Tunnelipordi avamine ei paljasta midagi muud, seega jääb ainult tunneli kaudu kättesaadav teenus oma avaliku pinna osas suletuks. See eraldatus on tavaliselt just põhjus, miks teenust üldse privaatsena hoida.

Sisemine poliitika on koht, kus juurdepääs tegelikult otsustatakse

Krüpteerimine kaitseb teed; see ei autoriseeri sihtkohta. Kliendi marsruudid valivad, millised prefiksid tunnelisse sisenevad, lüüsi edastuspoliitika otsustab, kas paketid tohivad sealt lahkuda, ning sihtkoha tulemüür ja sisselogimine otsustavad, kas teenus vastab. DNS on kõige selgem juhtum: päringute kandmine ei pane resolverit neid teie kliendipuldist vastu võtma. Iga kiht võib iseseisvalt öelda ei.

Testige iga teenust eraldi läbi tunneli. Edukas päring ei ütle midagi veebipordi kohta ja edukas veebipäring ei ütle midagi SSH kohta.

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

Kui tunnel töötab ja kõik ebaõnnestub, lugege esmalt kliendi marsruuditabelit. Kui üks teenus ebaõnnestub, samal ajal kui teised töötavad, on viga selles sihtkohas. Need kaks tähelepanekut osutavad erinevatele omanikele ja nende segamine raiskab aega.

WireGuard tõmbab sama joone

WireGuard nimetab oma välimist kuulajat ListenPort ja sisemine rakendus kasutab endiselt vajalikku teenuseporti. AllowedIPs on marsruuditud prefiksite kogum, mitte lubatud teenuseportide loend. Selle lugemine pordilubade loendina tekitab reegleid, mis ei vasta sellele, mida tunnel teeb. Nimetus on teine; kihilisus mitte.

Lubage teenus kohaliku sisendi poliitikas, kui see töötab lõpp-punktis endas, või edastuspoliitikas, kui see asub selle lõpp-punkti taga. See erinevus otsustab, milline reeglistik paketti näeb.

Üldine kuju on üks välimine transport paljude sisemiste vestlustega. Tooted, mis vajavad mitut välimist vahetust või teistsugust IP-protokolli, tuletavad meelde, et ühe avaliku pordi muster kirjeldab seda lahendust, mitte iga VPN-i.