Een OpenVPN-poort, drie dienste: waarom binne-poorte saak maak

Een SSH-sessie, een webtoepassing en een naamnavraag kan ’n enkele VPN-verbinding deel sonder om oor poorte te baklei. Die kliënt bou een geënkripteerde stroom na die poortweg, en elke toepassingsgesprek reis daarbinne. Van buite is net die tonnel se eie vervoer en poort sigbaar. Binne behou elke diens sy eie poort en het steeds sy eie toestemming nodig.

Wat die buitenste stroom dra, en wat dit wegsteek

Die kliënt verpak elke pakket in die tonnel se vervoer voordat dit die masjien verlaat. Daardie buitenste stroom het een bestemmingspoort, vasgestel toe die VPN opgestel is. Binne die verpakking behou elke oorspronklike pakket die adres en poort van die diens wat dit teiken. Die poortweg stroop die verpakking af en roeteer op die binne-kop, sodat die bestemming ’n gewone kliënt sien wat van die netwerk af aankom.

’n Opname op die WAN-koppelvlak wys dus een gesprek, nie drie nie. Die binne-poorte verskyn eers ná dekapsulering. Daarom kan ’n enkele vuurmuuropening SSH, HTTPS en DNS gelyktydig dra.

# 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

Die dokumentasie oor TUN/TAP dek die oorgang waar ’n gerouteerde TUN-toestel IP-pakkette tussen die kern en ’n gebruikersruimte-proses uitruil. Daardie oorgang is wat die binne-kop sigbaar maak vir die poortweg se roetering- en vuurmuurkode. Dit verduidelik ook waarom die buitenste poort niks sê oor watter dienste toegelaat word nie.

Die NAT-doorstuur hoort by die luisteraar, nie by die toepassings nie

’n Selftusgasheerde poortweg agter IPv4 NAT het een inkomende vertaling nodig: die publieke adres en poort wat na die VPN-luisteraar gekarteer word. Geen reël is nodig vir SSH, HTTPS of DNS bloot omdat tonnelgebruikers dit bereik nie. Om daardie poorte te publiseer, sou dienste blootstel wat die tonnel reeds beskerm. Die deurstuur-reël beskryf bereikbaarheid van die luisteraar, nie ’n toestemming vir enigiets binne nie.

Die omgekeerde geld ook. Om die tonnelpoort oop te maak, stel niks anders bloot nie, so ’n diens wat net deur die tonnel bereikbaar is, hou sy publieke oppervlak gesluit. Daardie skeiding is gewoonlik juis die rede om die diens privaat te hou.

Binne-beleid is waar toegang werklik beslis word

Enkripsie beskerm die pad; dit magtig nie ’n bestemming nie. Kliëntroetes kies watter voorvoegsels die tonnel binnegaan, die poortweg se deurstuurbeleid besluit of pakkette dit mag verlaat, en die bestemming se vuurmuur plus aanmelding besluit of die diens antwoord. DNS is die duidelikste geval: om navrae te dra, maak nie dat ’n oplosser dit uit jou kliëntpoel aanvaar nie. Elke laag kan onafhanklik nee sê.

Toets elke diens afsonderlik deur die tonnel. ’n Suksesvolle opsoek sê niks oor die webpoort nie, en ’n suksesvolle webversoek sê niks oor SSH nie.

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

Wanneer die tonnel op is en alles faal, lees eers die kliënt se roetekaart. Wanneer een diens faal terwyl die ander werk, sit die fout by daardie bestemming. Daardie twee waarnemings wys na verskillende eienaars, en om hulle te vermeng mors tyd.

WireGuard trek dieselfde lyn

WireGuard noem sy buitenste luisteraar met ListenPort, en ’n binne-toepassing gebruik steeds watter dienspoort dit ook nodig het. AllowedIPs is ’n stel gerouteerde voorvoegsels, nie ’n lys toegelate dienspoorte nie. Om dit as ’n poort-toelatingslys te lees, lewer reëls wat nie ooreenstem met wat die tonnel doen nie. Die benaming verskil; die gelaagdheid nie.

Laat die diens toe in plaaslike-invoerbeleid wanneer dit op die eindpunt self loop, of in deurstuurbeleid wanneer dit agter daardie eindpunt sit. Die onderskeid bepaal watter reëlversameling die pakket sien.

Die algemene vorm is een buitenste vervoer met baie binne-gesprekke. Produkte wat verskeie buitenste uitruilings of ’n ander IP-protokol nodig het, is ’n herinnering dat die patroon van een publieke poort hierdie ontwerp beskryf en nie elke VPN nie.