Maci VPN-seaded ei käivita serverit: kus asub lüüs

macOS-is kannab nime VPN kaks erinevat tööd ja seadete paneel tegeleb neist ainult ühega. Kui soovite, et selle Maci liiklus väljuks teenusepakkuja või kauglüüsi kaudu, piisab kliendikirjest. Kui soovite hotellitoast jõuda oma koduvõrgus oleva printeri, NAS-i või haldusleheni, peab midagi selles võrgus vastu võtma ühendusi väljastpoolt, ja praegune Mac ei ole see asi kohe karbist võttes. Kolm küsimust selgitavad, millises olukorras olete, ja neile tasub vastata enne, kui tipite väljale aadressi.

Kliendikirje nimetab sihtkohta, mitte kuulajat

macOS-i Ventura ja uuemates süsteemiseadetes > Võrk > VPN kirjeldavad väljad, mida vanemad versioonid hoiavad võrgu eelistustes, kuidas jõuda kellegi teise lõpp-punkti: serveri aadress, kaug-ID, konto või sertifikaat ja valikulised nõudmisel ühendamise reeglid. Selle kirje salvestamine hoiab ühenduse teie Maci võrgukonfiguratsioonis. Protsessis ei seota ühtegi porti, ei avata kuulajat ega registreerita kaugkasutajat.

Saate seda kestast kontrollida. Macis, mida kahtlustate teenivat, käivitage sudo lsof -nP -iUDP ja otsige porte, mida teie protokoll kasutab: 500 ja 4500 IKEv2 jaoks, 1194 OpenVPN-i vaikeväärtuse jaoks, 51820 WireGuardi jaoks. Ainult kliendina töötav masin näitab pesi, mis on seotud kaug-aadressi ja pordiga, mitte metamärgiga sidumist, kuhu miski internetis võiks jõuda. Network Extensioni sees töötavad tunnelid võivad lsof-i eest peituda, seega kontrollige igal juhul ka rakenduse enda olekupaneeli; mida te ei leia, on Apple'i eelistus, mis muudab selle Maci lüüsiks.

Kolm küsimust eristavad kahte rolli

Minge nendest järjekorras läbi. Esimene otsustab tavaliselt ülejäänu ja kolmas on koht, kus enamik Maci-spetsiifilist planeerimist untsu läheb.

1. Kes vestlust alustab? Kui teie Mac helistab välja ja teine pool vastab, vajate klienti. Kui internetis olevad seadmed peavad teie võrku jõudmiseks sisse helistama, vajate lüüsi avaliku sisenemispunktiga ja Mac võib jääda selle lüüsi kliendiks.

2. Mis peab olema kättesaadav, kui tunnel on üleval? Üks teenus ühes hostis on pordi edastamise otsus. Terve alamvõrk, sealhulgas nimede lahendamine, on marsruutimise ja DNS-i otsus ning see muudab seda, mida lüüs peab edastama, mitte seda, mida kliendikirje ütleb.

3. Milline OS-i versioon töötab vastuvõtvas otsas? Macide puhul on sellel küsimusel kõva vastus. Apple loetleb VPN-i macOS Server 5.7.1-st eemaldatuna ja macOS Serveri rakendus ise lõpetati 21. aprillil 2022; lehekülg, mida tasub lugeda, kui vana õpetus viib teid läbi VPN-teenuse märkeruudu, mida enam ei ole, on teadaanne teenuse ajaloo kohta.

Kui esimene vastus on „keegi väljastpoolt alustab”, lõpetage Maci kliendipaneelist lüliti otsimine ja valige host, mis tunneli lõpetab.

Kus lüüs võib selle asemel asuda

Neli lahendust katavad enamiku kodu- ja väikekontorijuhtumeid. Ruuter, millel on tõeline serverirežiim, mitte teise sildiga kliendirežiim, lõpetab tunneli servas ja hoiab hostide arvu väiksena, kuid seob teid selle püsivara protokollitoega. NAS või pidevalt töötav miniarvuti käivitab tootja serveripaketi ja jätab teile logid, mida saate lugeda. Väike pilve-VM annab teile avaliku aadressi, mida kontrollite, ja jõuab koju teise tunneli kaudu. WireGuardil põhinev võrgusilmkiht või haldusteenus, mis vahendab võrdsete vahel, mööduvad sissetuleva pordi edastamisest, lastes mõlemal otsal välja helistada.

Nende valikute vaheline piir on tavaliselt teie internetiühendus, mitte tarkvara. Kui teenusepakkuja paneb teid operaatoritasandi NAT-i taha, ei tekita ükski ruuteri pordi edastamine kättesaadavat sisenemispunkti ja aus vastus on vahendus- või võrgusilmlahendus. Võrrelge WAN-aadressi, millest teie ruuter teatab, aadressiga, mida näeb välismaailm; kui need erinevad ja ruuteri väärtus on privaatses või jagatud vahemikus, planeerige vahendusjuhtum.

Ükskõik millise hosti valite, edastage üks protokoll ühel pordil, mitte vahemikku, ja hoidke Mac sissetulevast teest eemal, kui just see konkreetne toode ei dokumenteeri serverirolli teie kasutatava macOS-i versiooni jaoks.

Kinnitage roll enne profiilide jagamist

Kandidaatlüüsil tõestage, et kuulaja on olemas, selle asemel et usaldada, et paigaldaja selle lõi. macOS-is tähendab see ülaltoodud portidele filtreeritud sudo lsof -nP -iUDP pluss sudo pfctl -s nat, kui paketifiltri reeglid on disaini osa. Linuxis näitab ss -lunp samu fakte ilma kahemõttelisuseta.

Seejärel testige väljastpoolt võrku, kasutades protokolli ennast. Ping tõestab vähe: ICMP-d filtreeritakse sageli ja see ei ütle UDP 51820 kohta midagi. Kliendi käepigistus üksikasjaliku logimisega, käivitatud telefonist mobiilsetel andmeside andmetel, on odavaim tõeline test, sest see läbib sama tee, mille läbib kaugkolleeg.

Alles pärast seda puudutage kliendiprofiile. Macis prindib scutil --nc list VPN-teenused, mida süsteem teab; kui äsja ehitatud lüüs nende hulgas pole, konfigureerite teist masinat kui see, mida testisite. Kui käepigistus õnnestub kohtvõrgus, kuid ebaõnnestub väljastpoolt, on viga sissetulevas tees: NAT-reegel, teenusepakkuja CGNAT või tulemüür lüüsil, täpselt selles järjekorras.

Enne millegi ehitamist otsustage neli punkti:

• Kumb pool ühenduse algatab, teie Mac või kaugseade.
• Kas vastuvõtva hosti OS-i versioon ja toode tõesti toetavad serverirolli.
• Kas teie teenusepakkuja annab üldse kättesaadava avaliku aadressi.
• Millise üksiku pordi ja protokolli lüüs vastu võtab ja milline teenus selle taga vastab.

Järgmine samm on konkreetne: valige lüüsi host, kinnitage selle kuulaja väljastpoolt ja alles siis looge Macis kliendikirje, mis sellele osutab.