Mac-VPN-innstillingene starter ikke en server: der gatewayen bor

To forskjellige jobber bærer navnet VPN i macOS, og innstillingspanelet håndterer bare én av dem. Hvis du vil at trafikken fra denne Macen skal gå ut gjennom en leverandør eller en ekstern gateway, holder en klientoppføring. Hvis du vil nå skriveren, NAS-en eller en administrasjonsside på hjemmenettet fra et hotellrom, må noe på det nettverket ta imot tilkoblinger utenfra, og en moderne Mac er ikke det noe av seg selv. Tre spørsmål avgjør hvilket tilfelle du er i, og de er verdt å svare på før du skriver en adresse i et felt.

En klientoppføring navngir en destinasjon, ikke en lytter

I Systeminnstillinger > Nettverk > VPN på macOS Ventura og nyere beskriver feltene som eldre versjoner holder under Nettverksinnstillinger hvordan du når andres endepunkt: en serveradresse, en ekstern ID, en konto eller et sertifikat, og valgfrie regler for tilkobling på forespørsel. Å lagre oppføringen lagrer en tilkobling i Macens nettverkskonfigurasjon. Ingenting i prosessen binder en port, åpner en lytter eller registrerer en ekstern bruker.

Du kan sjekke dette fra skallet. På en Mac du mistenker at tjener, kjør sudo lsof -nP -iUDP og se etter portene protokollen din bruker: 500 og 4500 for IKEv2, 1194 for OpenVPNs standard, 51820 for WireGuard. En maskin som bare er klient viser socketer koblet til en ekstern adresse og port, ikke en jokerbinding som noe på internett kunne nå. Tunneler som kjører i en Network Extension kan skjule seg for lsof, så sjekk appens eget statuspanel uansett; det du ikke finner er en Apple-innstilling som gjør denne Macen til gatewayen.

Tre spørsmål skiller de to rollene

Gå gjennom dem i rekkefølge. Det første avgjør vanligvis resten, og det tredje er der mest Mac-spesifikk planlegging går galt.

1. Hvem starter samtalen? Hvis Macen din ringer ut og den andre siden svarer, trenger du en klient. Hvis enheter på internett må ringe inn for å nå nettverket ditt, trenger du en gateway med et offentlig inngangspunkt, og Macen kan forbli klient av den gatewayen.

2. Hva må være tilgjengelig mens tunnelen er oppe? Én tjeneste på én vert er en avgjørelse om portvideresending. Et helt subnett, inkludert navneoppslag, er en avgjørelse om ruting og DNS, og det endrer hva gatewayen må videresende, ikke hva klientoppføringen sier.

3. Hvilken OS-versjon kjører den mottakende enden? For Macer har det spørsmålet et hardt svar. Apple lister VPN som fjernet fra macOS Server 5.7.1, og selve macOS Server-appen ble avviklet 21. april 2022; varselet om tjenestehistorikken er siden du bør lese når en gammel veiledning fører deg gjennom en avmerkingsboks for VPN-tjeneste som ikke finnes lenger.

Når det første svaret er «noen utenfra tar initiativet», slutt å lete etter en bryter i klientpanelet på Macen og gå og velg verten som skal avslutte tunnelen.

Hvor gatewayen kan bo i stedet

Fire ordninger dekker de fleste hjemme- og småkontortilfeller. En ruter med ekte servermodus, i motsetning til en klientmodus med en annen etikett, avslutter tunnelen ved kanten og holder vertstallet lavt, men til prisen av å være bundet til den fastvarens protokollstøtte. En NAS eller en alltid påslått mini-PC kjører leverandørens serverpakke og gir deg logger du kan lese. En liten sky-VM gir deg en offentlig adresse du kontrollerer og når hjem via en andre tunnel. Et mesh-overlegg bygget på WireGuard, eller en administrert tjeneste som videresender mellom parter, omgår innkommende portvideresending ved å la begge ender ringe ut.

Grensen mellom disse alternativene er vanligvis internettforbindelsen din, ikke programvaren. Hvis ISP-en setter deg bak carrier-grade NAT, gir ingen mengde portvideresending på ruteren et nåbart inngangspunkt, og en ordning med relay eller mesh er det ærlige svaret. Sammenlign WAN-adressen ruteren din rapporterer med adressen omverdenen ser; hvis de er forskjellige og ruterens verdi ligger i et privat eller delt område, planlegg for relay-tilfellet.

Uansett hvilken vert du velger, videresend én protokoll på én port i stedet for et område, og hold Macen utenfor den innkommende veien med mindre akkurat det produktet dokumenterer en serverrolle for macOS-versjonen du kjører.

Bekreft rollen før du deler ut profiler

På kandidat-gatewayen, bevis at en lytter finnes i stedet for å stole på at installasjonsprogrammet lagde en. På macOS betyr det sudo lsof -nP -iUDP filtrert til portene ovenfor, pluss sudo pfctl -s nat hvis regler for pakkefilter er en del av designet. På Linux viser ss -lunp de samme fakta uten tvetydighet.

Test deretter fra utenfor nettverket, med selve protokollen. Ping beviser lite: ICMP blir ofte filtrert og sier ingenting om UDP 51820. En klienthåndtrykk med detaljert logging, kjørt fra en telefon på mobildata, er den billigste ekte testen fordi den går samme vei som en ekstern kollega vil gå.

Først etter det rører du klientprofilene. På Macen skriver scutil --nc list ut VPN-tjenestene systemet kjenner; hvis gatewayen du nettopp bygde ikke er blant dem, konfigurerer du en annen maskin enn den du testet. Hvis håndtrykket lykkes på LAN-et men mislykkes utenfra, ligger feilen i den innkommende veien: NAT-regel, leverandørens CGNAT eller en brannmur på gatewayen, i den rekkefølgen.

Før du bygger noe, avgjør fire punkter:

• Hvilken side som tar initiativet til tilkoblingen, Macen din eller en ekstern enhet.
• Om OS-versjonen og produktet til den mottakende verten faktisk støtter en serverrolle.
• Om ISP-en din i det hele tatt gir deg en nåbar offentlig adresse.
• Hvilken enkelt port og protokoll gatewayen godtar, og hvilken tjeneste bak den som svarer.

Neste steg er konkret: velg gateway-verten, bekreft lytteren dens utenfra, og først da opprett klientoppføringen på Macen som peker på den.