Macens VPN-inställningar startar ingen server: där gatewayen bor

Två olika jobb bär namnet VPN i macOS, och inställningspanelen hanterar bara ett av dem. Om du vill att den här Macens trafik ska gå ut via en leverantör eller en fjärrgateway räcker en klientpost. Om du vill nå skrivaren, NAS:en eller en admin-sida på hemnätet från ett hotellrum måste något på det nätet ta emot anslutningar utifrån, och en modern Mac är inte det något av sig själv. Tre frågor avgör vilket fall du är i, och de är värda att besvara innan du skriver en adress i ett fält.

En klientpost namnger en destination, inte en lyssnare

I Systeminställningar > Nätverk > VPN på macOS Ventura och senare beskriver fälten som äldre versioner har under Nätverksinställningar hur du når någon annans slutpunkt: en serveradress, ett fjärr-ID, ett konto eller certifikat och valfria regler för anslutning på begäran. Att spara posten lagrar en anslutning i Macens nätverkskonfiguration. Ingenting i processen binder en port, öppnar en lyssnare eller registrerar en fjärranvändare.

Du kan kontrollera detta från skalet. På en Mac som du misstänker tjänar, kör sudo lsof -nP -iUDP och leta efter portarna som ditt protokoll använder: 500 och 4500 för IKEv2, 1194 för OpenVPNs standard, 51820 för WireGuard. En maskin som bara är klient visar sockets parade med en fjärradress och port, inte en jokerbindning som vad som helst på internet skulle kunna nå. Tunnlar som körs i en Network Extension kan gömma sig för lsof, så kontrollera appens statuspanel ändå; det du inte hittar är en Apple-inställning som gör den här Macen till gateway.

Tre frågor skiljer de två rollerna

Gå igenom dem i ordning. Den första avgör oftast resten, och den tredje är där mest Mac-specifik planering går fel.

1. Vem startar samtalet? Om din Mac ringer ut och andra sidan svarar behöver du en klient. Om enheter på internet måste ringa in för att nå ditt nätverk behöver du en gateway med en offentlig ingång, och Macen kan förbli klient hos den gatewayen.

2. Vad måste vara nåbart medan tunneln är uppe? En tjänst på en värd är ett beslut om portvidarebefordran. Ett helt subnät, inklusive namnmatchning, är ett beslut om routning och DNS, och det ändrar vad gatewayen måste vidarebefordra, inte vad klientposten säger.

3. Vilken OS-version kör den mottagande änden? För Macar har den frågan ett hårt svar. Apple listar VPN som borttaget från macOS Server 5.7.1, och själva macOS Server-appen lades ned den 21 april 2022; meddelandet om tjänstehistoriken är sidan du bör läsa när en gammal guide leder dig genom en kryssruta för en VPN-tjänst som inte längre finns.

När det första svaret är ”någon utifrån tar initiativet”, sluta leta efter en brytare i Macens klientpanel och gå och välj den värd som ska avsluta tunneln.

Var gatewayen kan bo i stället

Fyra arrangemang täcker de flesta hem- och småkontorsfall. En router med ett äkta serverläge, till skillnad från ett klientläge med en annan etikett, avslutar tunneln vid kanten och håller värdantalet lågt, till priset av att vara bunden till den firmwarens protokollstöd. En NAS eller en alltid påslagen mini-PC kör leverantörens serverpaket och lämnar loggar du kan läsa. En liten moln-VM ger dig en offentlig adress du kontrollerar och når hem via en andra tunnel. Ett mesh-overlay byggt på WireGuard, eller en hanterad tjänst som vidarebefordrar mellan parter, kringgår inkommande portvidarebefordran genom att låta båda ändarna ringa ut.

Gränsen mellan de alternativen är oftast din internetanslutning, inte programvaran. Om ISP:n sätter dig bakom carrier-grade NAT ger ingen mängd portvidarebefordran i routern en nåbar ingång, och ett arrangemang med relay eller mesh är det ärliga svaret. Jämför WAN-adressen som routern rapporterar med adressen som omvärlden ser; om de skiljer sig och routerns värde ligger i ett privat eller delat intervall, planera för relay-fallet.

Vilken värd du än väljer, vidarebefordra ett protokoll på en port i stället för ett intervall, och håll Macen utanför den inkommande vägen om inte just den produkten dokumenterar en serverroll för den macOS-version du kör.

Bekräfta rollen innan du delar ut profiler

På kandidat-gatewayen, bevisa att en lyssnare finns i stället för att lita på att installationsprogrammet skapade en. På macOS betyder det sudo lsof -nP -iUDP filtrerat till portarna ovan, plus sudo pfctl -s nat om regler för paketfilter ingår i designen. På Linux visar ss -lunp samma fakta utan tvetydighet.

Testa sedan från utanför nätverket, med själva protokollet. Ping bevisar lite: ICMP filtreras ofta och säger ingenting om UDP 51820. Ett klientshandskakning med detaljerad loggning, körd från en telefon på mobildata, är det billigaste riktiga testet eftersom det går samma väg som en fjärrkollega kommer att gå.

Först därefter rör du klientprofilerna. På Macen skriver scutil --nc list ut de VPN-tjänster systemet känner till; om gatewayen du just byggde inte är bland dem konfigurerar du en annan maskin än den du testade. Om handskakningen lyckas på LAN men misslyckas utifrån ligger felet i den inkommande vägen: NAT-regel, leverantörens CGNAT eller en brandvägg på gatewayen, i den ordningen.

Innan du bygger något, avgör fyra punkter:

• Vilken sida som tar initiativet till anslutningen, din Mac eller en fjärrenhet.
• Om OS-versionen och produkten för den mottagande värden faktiskt stöder en serverroll.
• Om din ISP över huvud taget ger dig en nåbar offentlig adress.
• Vilken enda port och protokoll gatewayen accepterar, och vilken tjänst bakom den som svarar.

Nästa steg är konkret: välj gateway-värden, bekräfta dess lyssnare utifrån, och först då skapa klientposten på Macen som pekar på den.