Mac-VPN-indstillinger starter ikke en server: hvor gatewayen bor

To forskellige opgaver bærer navnet VPN i macOS, og indstillingspanelet håndterer kun én af dem. Hvis du vil have denne Macs trafik til at gå ud gennem en udbyder eller en fjern gateway, er en klientpost alt, du behøver. Hvis du vil nå printeren, NAS'en eller en administrationsside på dit hjemmenetværk fra et hotelværelse, så skal noget på det netværk acceptere forbindelser udefra, og en nuværende Mac er ikke den ting lige ud af boksen. Tre spørgsmål afgør, hvilket tilfælde du er i, og de er værd at besvare, før du skriver en adresse i et felt.

En klientpost angiver en destination, ikke en lytter

I Systemindstillinger > Netværk > VPN på macOS Ventura og nyere beskriver de felter, som ældre versioner har under Netværksindstillinger, hvordan man når en andens slutpunkt: en serveradresse, et fjern-ID, en konto eller et certifikat og valgfrie regler for forbindelse på anmodning. Gemmer du den post, gemmes en forbindelse i din Macs netværkskonfiguration. Intet i processen binder en port, åbner en lytter eller tilmelder en fjernbruger.

Det kan du tjekke fra skallen. På en Mac, som du mistænker for at betjene, kør sudo lsof -nP -iUDP og se efter de porte, din protokol bruger: 500 og 4500 til IKEv2, 1194 til OpenVPNs standard, 51820 til WireGuard. En maskine, der kun er klient, viser sockets parret med en fjernadresse og -port, ikke en jokerbindning, som noget på internettet kunne nå. Tunneler, der kører inde i en Network Extension, kan skjule sig for lsof, så tjek under alle omstændigheder også appens eget statuspanel; det, du ikke finder, er en Apple-indstilling, der gør denne Mac til gatewayen.

Tre spørgsmål skiller de to roller

Gå dem igennem i rækkefølge. Det første afgør som regel resten, og det tredje er der, hvor det meste Mac-specifikke planlægning går galt.

1. Hvem starter samtalen? Hvis din Mac ringer ud, og den anden side svarer, har du brug for en klient. Hvis enheder på internettet skal ringe ind for at nå dit netværk, har du brug for en gateway med et offentligt indgangspunkt, og Macen kan forblive klient hos den gateway.

2. Hvad skal være tilgængeligt, mens tunnelen er oppe? Én tjeneste på én vært er en videresendelse af en port. Et helt undernet, inklusive navneopslag, er en routing- og DNS-beslutning, og det ændrer, hvad gatewayen skal videresende, snarere end hvad klientposten siger.

3. Hvilken OS-version kører den accepterende ende? For Macs har det spørgsmål et hårdt svar. Apple angiver VPN som fjernet fra macOS Server 5.7.1, og selve macOS Server-appen blev nedlagt 21. april 2022; den side, du bør læse, når en gammel vejledning fører dig gennem et afkrydsningsfelt for VPN-tjenesten, som ikke findes mere, er meddelelsen om tjenestens historie.

Når det første svar er “nogen udefra starter”, så hold op med at lede efter en kontakt i Macens klientpanel, og vælg den vært, der skal afslutte tunnelen.

Hvor gatewayen i stedet kan bo

Fire arrangementer dækker de fleste hjemme- og småkontortilfælde. En router med en ægte servertilstand, i modsætning til en klienttilstand med en anden etiket, afslutter tunnelen ved kanten og holder antallet af værter nede, men binder dig til den firmwares protokolunderstøttelse. En NAS eller en altid tændt mini-PC kører leverandørens serverpakke og efterlader logs, du kan læse. En lille sky-VM giver dig en offentlig adresse, du kontrollerer, og når hjem over en anden tunnel. Et mesh-overlay bygget på WireGuard, eller en administreret tjeneste, der videresender mellem peers, omgår indgående portvideresendelse ved at lade begge ender ringe ud.

Grænsen mellem de muligheder er som regel din internetforbindelse, ikke softwaren. Hvis udbyderen sætter dig bag carrier-grade NAT, giver ingen mængde portvideresendelse på routeren et tilgængeligt indgangspunkt, og et relay- eller mesh-arrangement er det ærlige svar. Sammenlign den WAN-adresse, din router rapporterer, med den adresse, omverdenen ser; hvis de er forskellige, og routerens værdi ligger i et privat eller delt interval, så planlæg relay-tilfældet.

Uanset hvilken vært du vælger, videresend én protokol på én port i stedet for et interval, og hold Macen ude af den indgående vej, medmindre netop det produkt dokumenterer en serverrolle for den macOS-version, du kører.

Bekræft rollen, før du udleverer profiler

På den mulige gateway skal du bevise, at en lytter findes, i stedet for at stole på, at installationsprogrammet har oprettet en. På macOS betyder det sudo lsof -nP -iUDP filtreret til portene ovenfor plus sudo pfctl -s nat, hvis pakkefilterregler er en del af designet. På Linux viser ss -lunp de samme fakta uden tvetydighed.

Test derefter udefra netværket med selve protokollen. Ping beviser lidt: ICMP filtreres ofte og siger intet om UDP 51820. Et klient-håndtryk med detaljeret logning, kørt fra en telefon på mobildata, er den billigste rigtige test, fordi det krydser den samme vej, som en fjern kollega vil.

Først derefter rører du klientprofilerne. På Macen udskriver scutil --nc list de VPN-tjenester, systemet kender; hvis den gateway, du netop har bygget, ikke er blandt dem, konfigurerer du en anden maskine end den, du testede. Hvis håndtrykket lykkes på LAN'et men fejler udefra, ligger fejlen i den indgående vej: NAT-regel, udbyderens CGNAT eller en firewall på gatewayen, i den rækkefølge.

Før du bygger noget, skal du afgøre fire punkter:

• Hvilken side der starter forbindelsen, din Mac eller en fjernenhed.
• Om den accepterende værts OS-version og produkt faktisk understøtter en serverrolle.
• Om din udbyder overhovedet giver dig en tilgængelig offentlig adresse.
• Hvilken enkelt port og protokol gatewayen accepterer, og hvilken tjeneste bagved der svarer.

Det næste skridt er konkret: vælg gateway-værten, bekræft dens lytter udefra, og først derefter opret klientposten på Macen, der peger på den.