Setările VPN de pe Mac nu pornesc un server: unde locuiește gateway-ul

Două sarcini diferite poartă numele VPN în macOS, iar panoul de setări se ocupă doar de una dintre ele. Dacă vrei ca traficul acestui Mac să iasă printr-un furnizor sau printr-un gateway la distanță, este suficientă o intrare de client. Dacă vrei să ajungi la imprimantă, la NAS sau la o pagină de administrare din rețeaua de acasă dintr-o cameră de hotel, ceva din acea rețea trebuie să accepte conexiuni din exterior, iar un Mac actual nu este acel ceva din start. Trei întrebări stabilesc în ce caz te afli, și merită să le răspunzi înainte de a tasta o adresă într-un câmp.

O intrare de client numește o destinație, nu un ascultător

În Setări de sistem > Rețea > VPN pe macOS Ventura și versiunile ulterioare, câmpurile pe care versiunile mai vechi le țin sub Preferințe de rețea descriu cum să ajungi la punctul final al altcuiva: o adresă de server, un ID la distanță, un cont sau un certificat și reguli opționale de conectare la cerere. Salvarea acelei intrări stochează o conexiune în configurația de rețea a Mac-ului tău. Nimic din proces nu leagă un port, nu deschide un ascultător și nu înregistrează un utilizator la distanță.

Poți verifica acest lucru din shell. Pe un Mac despre care suspectezi că servește, rulează sudo lsof -nP -iUDP și caută porturile folosite de protocolul tău: 500 și 4500 pentru IKEv2, 1194 pentru implicitul OpenVPN, 51820 pentru WireGuard. O mașină doar client arată socketuri împerecheate cu o adresă și un port la distanță, nu o legare universală pe care orice de pe internet ar putea-o atinge. Tunelurile care rulează într-o Network Extension se pot ascunde de lsof, așa că verifică oricum panoul de stare al aplicației; ceea ce nu vei găsi este o preferință Apple care transformă acest Mac în gateway.

Trei întrebări despart cele două roluri

Parcurge-le în ordine. Prima decide de obicei restul, iar a treia este locul unde majoritatea planificării specifice Mac greșește.

1. Cine începe conversația? Dacă Mac-ul tău apelează spre exterior și cealaltă parte răspunde, ai nevoie de un client. Dacă dispozitivele din internet trebuie să apeleze spre interior ca să ajungă la rețeaua ta, ai nevoie de un gateway cu un punct de intrare public, iar Mac-ul poate rămâne client al acelui gateway.

2. Ce trebuie să fie accesibil cât timp tunelul este ridicat? Un serviciu pe un singur host este o decizie de redirecționare a porturilor. O subrețea întreagă, inclusiv rezolvarea numelor, este o decizie de rutare și DNS, și schimbă ceea ce trebuie să transmită gateway-ul, nu ceea ce spune intrarea de client.

3. Ce versiune de sistem rulează capătul care acceptă? Pentru Mac-uri această întrebare are un răspuns dur. Apple listează VPN ca eliminat din macOS Server 5.7.1, iar aplicația macOS Server în sine a fost retrasă la 21 aprilie 2022; notificarea privind istoricul serviciului este pagina de citit atunci când un tutorial vechi te trece printr-o casetă de serviciu VPN care nu mai există.

Când primul răspuns este „cineva din exterior începe”, oprește căutarea unui comutator în panoul de client al Mac-ului și mergi să alegi hostul care va termina tunelul.

Unde poate locui gateway-ul în schimb

Patru aranjamente acoperă majoritatea cazurilor de acasă și de birou mic. Un router cu un mod server veritabil, spre deosebire de un mod client cu altă etichetă, termină tunelul la margine și ține numărul de hosturi mic, cu prețul de a fi legat de suportul de protocoale al acelui firmware. Un NAS sau un mini PC pornit mereu rulează pachetul de server al producătorului și îți lasă jurnale pe care le poți citi. O mică VM în cloud îți dă o adresă publică pe care o controlezi și ajunge acasă printr-un al doilea tunel. O suprapunere mesh construită pe WireGuard, sau un serviciu administrat care retransmite între parteneri, ocolește redirecționarea porturilor de intrare făcând ambele capete să apeleze spre exterior.

Grană dintre acele opțiuni este de obicei conexiunea ta la internet, nu software-ul. Dacă furnizorul te pune în spatele unui NAT de nivel de operator, nicio cantitate de redirecționare a porturilor pe router nu produce un punct de intrare accesibil, iar un aranjament cu relay sau mesh este răspunsul onest. Compară adresa WAN raportată de router cu adresa pe care o vede lumea exterioară; dacă diferă și valoarea routerului se află într-un interval privat sau partajat, planifică cazul relay.

Orice host ai alege, redirecționează un protocol pe un port, nu un interval, și ține Mac-ul în afara căii de intrare, cu excepția cazului în care acel produs anume documentează un rol de server pentru versiunea de macOS pe care o rulezi.

Confirmă rolul înainte de a distribui profiluri

Pe gateway-ul candidat, dovedește că există un ascultător în loc să te bazezi pe faptul că instalatorul a creat unul. Pe macOS asta înseamnă sudo lsof -nP -iUDP filtrat pe porturile de mai sus, plus sudo pfctl -s nat dacă regulile de filtrare a pachetelor fac parte din proiect. Pe Linux, ss -lunp arată aceleași fapte fără ambiguitate.

Apoi testează din afara rețelei, folosind protocolul însuși. Ping dovedește puțin: ICMP este adesea filtrat și nu spune nimic despre UDP 51820. Un handshake de client cu jurnalizare detaliată, rulat de pe un telefon pe date mobile, este cel mai ieftin test real pentru că trece pe același drum pe care va trece un coleg la distanță.

Abia după aceea atingi profilurile de client. Pe Mac, scutil --nc list tipărește serviciile VPN pe care sistemul le cunoaște; dacă gateway-ul tocmai construit nu este printre ele, configurezi o altă mașină decât cea pe care ai testat-o. Dacă handshake-ul reușește în LAN dar eșuează din exterior, vina este pe calea de intrare: regulă NAT, CGNAT-ul furnizorului sau un firewall pe gateway, în această ordine.

Înainte de a construi ceva, lămurește patru puncte:

• Care parte inițiază conexiunea, Mac-ul tău sau un dispozitiv la distanță.
• Dacă versiunea de sistem și produsul hostului care acceptă susțin cu adevărat un rol de server.
• Dacă furnizorul tău îți dă măcar o adresă publică accesibilă.
• Ce singur port și protocol va accepta gateway-ul și ce serviciu din spate răspunde.

Următorul pas este concret: alege hostul gateway-ului, confirmă-i ascultătorul din exterior și abia apoi creează pe Mac intrarea de client care indică spre el.