Eén OpenVPN-poort, drie diensten: waarom binnenpoorten ertoe doen
Eén tunnel, drie diensten, één openbare poort. Scheid de buitenste VPN-listener van de binnenste applicatiepoorten en test elke binnenste toestemming apart.
Eén SSH-sessie, één webapp en één naamopzoeking kunnen één VPN-verbinding delen zonder om poorten te vechten. De client bouwt één versleutelde stroom naar de gateway, en elk applicatiegesprek reist daarbinnen. Buiten is alleen het eigen transport en de poort van de tunnel zichtbaar. Binnen houdt elke dienst zijn eigen poort en heeft nog steeds zijn eigen toestemming nodig.
Wat de buitenste stroom draagt, en wat hij verbergt
De client wikkelt elk pakket in het transport van de tunnel voordat het de machine verlaat. Die buitenste stroom heeft één bestemmingspoort, vastgelegd toen de VPN werd geconfigureerd. Binnen de wikkel behoudt elk oorspronkelijk pakket het adres en de poort van de dienst waarop het is gericht. De gateway verwijdert de wikkel en routeert op de binnenste header, zodat de bestemming een gewone client ziet die uit het netwerk aankomt.
Een opname op de WAN-interface toont daarom één gesprek, niet drie. De binnenpoorten verschijnen pas na decapsulatie. Daarom kan één firewallopening SSH, HTTPS en DNS tegelijk dragen.
# 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
De TUN/TAP-documentatie beschrijft de overdracht waarbij een gerouteerd TUN-apparaat IP-pakketten tussen de kernel en een gebruikersruimteproces doorgeeft. Die overdracht maakt de binnenste header zichtbaar voor de routerings- en firewallcode van de gateway. Ze verklaart ook waarom de buitenpoort niets zegt over welke diensten zijn toegestaan.
De NAT-forward hoort bij de listener, niet bij de applicaties
Een zelfgehoste gateway achter IPv4-NAT heeft één inkomende vertaling nodig: het openbare adres en de poort worden aan de VPN-listener gekoppeld. Er is geen regel nodig voor SSH, HTTPS of DNS alleen omdat tunnelgebruikers ze bereiken. Die poorten publiceren zou diensten blootleggen die de tunnel al beschermt. De doorstuurrege beschrijft de bereikbaarheid van de listener, niet een toestemming voor iets binnenin.
Het omgekeerde geldt ook. Het openen van de tunnelpoort legt niets anders bloot, dus een dienst die alleen via de tunnel bereikbaar is, houdt zijn openbare oppervlak gesloten. Die scheiding is meestal de reden om de dienst privé te houden.
Het binnenbeleid is waar toegang werkelijk wordt beslist
Versleuteling beschermt het pad; ze machtigt geen bestemming. Clientroutes kiezen welke prefixen de tunnel in gaan, het doorstuurbeleid van de gateway beslist of pakketten hem mogen verlaten, en de firewall plus login van de bestemming beslissen of de dienst antwoordt. DNS is het duidelijkste geval: query's dragen maakt een resolver niet bereid ze van jouw clientpool te accepteren. Elke laag kan onafhankelijk nee zeggen.
Test elke dienst afzonderlijk via de tunnel. Een geslaagde opzoeking zegt niets over de webpoort, en een geslaagd webverzoek zegt niets over SSH.
dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]
Als de tunnel actief is en alles faalt, lees dan eerst de routetabel van de client. Als één dienst faalt terwijl de andere werken, zit de fout bij die bestemming. Die twee waarnemingen wijzen naar verschillende eigenaren, en ze door elkaar halen kost tijd.
WireGuard trekt dezelfde grens
WireGuard noemt zijn buitenste listener ListenPort, en een binnenste applicatie gebruikt nog steeds de dienstpoort die ze nodig heeft. AllowedIPs is een verzameling gerouteerde prefixen, geen lijst van toegestane dienstpoorten. Het lezen als een poort-allowlist levert regels op die niet kloppen met wat de tunnel doet. De naamgeving is anders; de gelaagdheid niet.
Sta de dienst toe in het lokale inputbeleid wanneer hij op de endpoint zelf draait, of in het doorstuurbeleid wanneer hij achter die endpoint zit. Dat onderscheid bepaalt welke regelset het pakket ziet.
De algemene vorm is één buitenste transport met veel binnenste gesprekken. Producten die meerdere buitenste uitwisselingen of een ander IP-protocol nodig hebben, herinneren eraan dat het patroon met één openbare poort dit ontwerp beschrijft en niet elke VPN.