Viens OpenVPN ports, trīs pakalpojumi: kāpēc svarīgi iekšējie porti

Viena SSH sesija, viena tīmekļa lietotne un viens vārdu vaicājums var dalīt vienu VPN savienojumu, nekonkurējot par portiem. Klients izveido vienu šifrētu plūsmu uz vārteju, un katra lietotnes saruna ceļo tās iekšienē. Ārpusē ir redzams tikai paša tuneļa transports un ports. Iekšpusē katrs pakalpojums saglabā savu portu un joprojām prasa savu atļauju.

Ko nes ārējā plūsma un ko tā slēpj

Klients iesaiņo katru paketi tuneļa transportā pirms tās iziešanas no mašīnas. Šai ārējai plūsmai ir viens galamērķa ports, kas noteikts, kad VPN tika konfigurēts. Iesaiņojuma iekšienē katra sākotnējā pakete saglabā tā pakalpojuma adresi un portu, uz kuru tā ir vērsta. Vārteja noņem iesaiņojumu un maršrutē pēc iekšējās galvenes, tāpēc galamērķis redz parastu klientu, kas ierodas no tīkla.

Tāpēc WAN saskarnes uzņemšana rāda vienu sarunu, nevis trīs. Iekšējie porti parādās tikai pēc dekapsulācijas. Tāpēc viens ugunsmūra atvērums var vienlaikus pārvadāt SSH, HTTPS un 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

TUN/TAP dokumentācija apraksta nodošanu, kurā maršrutēta TUN ierīce nodod IP paketes starp kodolu un lietotāja telpas procesu. Šī nodošana ir tas, kas padara iekšējo galveni redzamu vārtejas maršrutēšanas un ugunsmūra kodam. Tā arī izskaidro, kāpēc ārējais ports neko nepasaka par to, kuri pakalpojumi ir atļauti.

NAT pāradresācija pieder klausītājam, nevis lietotnēm

Pašmitinātai vārtejai aiz IPv4 NAT ir vajadzīga viena ienākošā tulkošana: publiskā adrese un ports tiek kartēti uz VPN klausītāju. Nav vajadzīgs neviens noteikums SSH, HTTPS vai DNS tikai tāpēc, ka tuneļa lietotāji tos sasniedz. Šo portu publicēšana atklātu pakalpojumus, kurus tunelis jau aizsargā. Pāradresācijas noteikums apraksta klausītāja sasniedzamību, nevis atļauju kaut kam iekšpusē.

Der arī pretējais. Tuneļa porta atvēršana neko citu neatklāj, tāpēc pakalpojums, kas sasniedzams tikai caur tuneli, saglabā savu publisko virsmu slēgtu. Šī atdalīšana parasti ir iemesls, kāpēc pakalpojums tiek turēts privāts.

Iekšējā politika ir vieta, kur piekļuve faktiski tiek izlemta

Šifrēšana aizsargā ceļu; tā nepiešķir pilnvaras galamērķim. Klienta maršruti izvēlas, kuri prefiksi nokļūst tunelī, vārtejas pāradresācijas politika izlemj, vai paketes drīkst to atstāt, un galamērķa ugunsmūris kopā ar pieteikšanos izlemj, vai pakalpojums atbild. DNS ir visskaidrākais gadījums: vaicājumu pārvadāšana nepadara risinātāju gatavu tos pieņemt no jūsu klientu kopas. Katrs slānis var atteikt neatkarīgi.

Pārbaudiet katru pakalpojumu atsevišķi caur tuneli. Veiksmīgs vaicājums neko nepasaka par tīmekļa portu, un veiksmīgs tīmekļa pieprasījums neko nepasaka par SSH.

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

Kad tunelis ir aktīvs un viss neizdodas, vispirms lasiet klienta maršrutu tabulu. Kad viens pakalpojums neizdodas, bet pārējie strādā, kļūda ir šajā galamērķī. Šie divi novērojumi norāda uz dažādiem atbildīgajiem, un to sajaukšana tērē laiku.

WireGuard novelk to pašu līniju

WireGuard savu ārējo klausītāju nosauc ar nosaukumu ListenPort, un iekšējā lietotne joprojām izmanto to pakalpojuma portu, kāds tai vajadzīgs. AllowedIPs ir maršrutētu prefiksu kopa, nevis atļauto pakalpojuma portu saraksts. Lasot to kā portu atļauto sarakstu, tiek iegūti noteikumi, kas neatbilst tam, ko dara tunelis. Nosaukums atšķiras; slāņojums ne.

Atļaujiet pakalpojumu vietējās ievades politikā, ja tas darbojas pašā galapunktā, vai pāradresācijas politikā, ja tas atrodas aiz šī galapunkta. Šī atšķirība izlemj, kurš noteikumu kopums redz paketi.

Vispārējā forma ir viens ārējais transports ar daudzām iekšējām sarunām. Produkti, kuriem vajadzīgas vairākas ārējās apmaiņas vai cits IP protokols, atgādina, ka viena publiskā porta modelis apraksta šo dizainu, nevis katru VPN.