Mac-VPN-instellingen starten geen server: waar de gateway woont

Twee verschillende taken dragen de naam VPN in macOS, en het instellingenpaneel behandelt er maar één van. Wil je dat het verkeer van deze Mac via een provider of een externe gateway naar buiten gaat, dan volstaat een clientvermelding. Wil je vanuit een hotelkamer de printer, de NAS of een beheerpagina op je thuisnetwerk bereiken, dan moet iets op dat netwerk verbindingen van buitenaf accepteren, en een huidige Mac is dat iets niet standaard. Drie vragen bepalen in welk geval je zit, en het loont ze te beantwoorden voordat je een adres in een veld typt.

Een clientvermelding noemt een bestemming, geen listener

In Systeeminstellingen > Netwerk > VPN op macOS Ventura en later beschrijven de velden die oudere versies onder Netwerkvoorkeuren bewaren hoe je iemands anders endpoint bereikt: een serveradres, een remote ID, een account of certificaat, en optionele regels voor verbinden op verzoek. Die vermelding opslaan bewaart een verbinding in de netwerkconfiguratie van je Mac. Niets in het proces bindt een poort, opent een listener of schrijft een externe gebruiker in.

Je kunt dit vanuit de shell controleren. Op een Mac waarvan je vermoedt dat hij dient, voer je sudo lsof -nP -iUDP uit en zoek je de poorten die je protocol gebruikt: 500 en 4500 voor IKEv2, 1194 voor de standaard van OpenVPN, 51820 voor WireGuard. Een machine die alleen client is toont sockets gekoppeld aan een extern adres en een externe poort, niet een wildcard-binding die alles op het internet zou kunnen bereiken. Tunnels die in een Network Extension draaien kunnen zich voor lsof verbergen, dus controleer hoe dan ook het statuspaneel van de app; wat je niet zult vinden is een Apple-voorkeur die deze Mac tot gateway maakt.

Drie vragen scheiden de twee rollen

Werk ze in volgorde af. De eerste bepaalt meestal de rest, en de derde is waar de meeste Mac-specifieke planning misgaat.

1. Wie begint het gesprek? Als je Mac naar buiten belt en de andere kant antwoordt, heb je een client nodig. Als apparaten op het internet naar binnen moeten bellen om je netwerk te bereiken, heb je een gateway met een openbaar toegangspunt nodig, en de Mac kan client van die gateway blijven.

2. Wat moet bereikbaar zijn terwijl de tunnel staat? Eén dienst op één host is een beslissing over port forwarding. Een heel subnet, inclusief naamresolutie, is een beslissing over routing en DNS, en dat verandert wat de gateway moet doorsturen, niet wat de clientvermelding zegt.

3. Welke OS-versie draait het accepterende uiteinde? Voor Macs heeft die vraag een hard antwoord. Apple vermeldt VPN als verwijderd uit macOS Server 5.7.1, en de macOS Server-app zelf werd op 21 april 2022 stopgezet; de kennisgeving over de dienstgeschiedenis is de pagina die je moet lezen wanneer een oude handleiding je langs een selectievakje voor een VPN-dienst leidt dat niet meer bestaat.

Als het eerste antwoord “iemand van buiten begint” is, stop dan met zoeken naar een schakelaar in het clientpaneel van de Mac en kies de host die de tunnel beëindigt.

Waar de gateway anders kan wonen

Vier opstellingen dekken de meeste thuis- en kleine kantoorgevallen. Een router met een echte servermodus, in tegenstelling tot een clientmodus met een ander label, beëindigt de tunnel aan de rand en houdt het aantal hosts laag, tegen de prijs dat je vastzit aan de protocolondersteuning van die firmware. Een NAS of een altijd aanstaande mini-pc draait het serverpakket van de leverancier en laat je logs die je kunt lezen. Een kleine cloud-VM geeft je een openbaar adres dat je beheert en bereikt thuis via een tweede tunnel. Een mesh-overlay op WireGuard, of een beheerde dienst die tussen peers doorgeeft, omzeilt inkomende port forwarding door beide uiteinden naar buiten te laten bellen.

De grens tussen die opties is meestal je internetverbinding, niet de software. Als de provider je achter carrier-grade NAT zet, levert geen enkele port forwarding op de router een bereikbaar toegangspunt op, en dan is een relay- of mesh-opstelling het eerlijke antwoord. Vergelijk het WAN-adres dat je router meldt met het adres dat de buitenwereld ziet; verschillen ze en ligt de waarde van de router in een privé- of gedeeld bereik, plan dan voor het relay-geval.

Welke host je ook kiest, stuur één protocol op één poort door in plaats van een bereik, en houd de Mac buiten het inkomende pad tenzij dat specifieke product een serverrol documenteert voor de macOS-versie die je draait.

Bevestig de rol voordat je profielen uitgeeft

Bewijs op de kandidaat-gateway dat er een listener bestaat in plaats van te vertrouwen op de installatie. Op macOS betekent dat sudo lsof -nP -iUDP gefilterd op de poorten hierboven, plus sudo pfctl -s nat als packetfilterregels deel van het ontwerp zijn. Op Linux toont ss -lunp dezelfde feiten zonder dubbelzinnigheid.

Test daarna van buiten het netwerk, met het protocol zelf. Ping bewijst weinig: ICMP wordt vaak gefilterd en zegt niets over UDP 51820. Een clienthandshake met uitgebreide logging, uitgevoerd vanaf een telefoon op mobiele data, is de goedkoopste echte test omdat hij hetzelfde pad volgt als een collega op afstand.

Pas daarna raak je clientprofielen aan. Op de Mac drukt scutil --nc list de VPN-diensten af die het systeem kent; staat de gateway die je zojuist bouwde er niet bij, dan configureer je een andere machine dan je hebt getest. Als de handshake op de LAN lukt maar van buitenaf mislukt, zit de fout in het inkomende pad: NAT-regel, CGNAT van de provider of een firewall op de gateway, in die volgorde.

Voordat je iets bouwt, beslis je vier punten:

• Welke kant de verbinding begint, je Mac of een apparaat op afstand.
• Of de OS-versie en het product van de accepterende host echt een serverrol ondersteunen.
• Of je provider je überhaupt een bereikbaar openbaar adres geeft.
• Welke enkele poort en welk protocol de gateway accepteert, en welke dienst erachter antwoordt.

De volgende stap is concreet: kies de gateway-host, bevestig de listener van buitenaf, en pas dan maak de clientvermelding op de Mac die ernaar wijst.