Настройките на VPN за Mac не стартират сървър: къде живее шлюзът

Две различни задачи носят името VPN в macOS и панелът с настройки се занимава само с една от тях. Ако искате трафикът на този Mac да излиза през доставчик или отдалечен шлюз, записът за клиент е всичко, което ви трябва. Ако искате да стигнете до принтера, NAS или административна страница в домашната си мрежа от хотелска стая, тогава нещо в тази мрежа трябва да приема връзки отвън, а настоящият Mac не е това нещо веднага от кутията. Три въпроса решават в кой случай сте и си заслужава да им отговорите, преди да въведете адрес в поле.

Записът за клиент назовава дестинация, а не слушател

В Системни настройки > Мрежа > VPN на macOS Ventura и по-нови полетата, които по-старите версии пазят под Мрежови предпочитания, описват как да стигнете до крайна точка на някой друг: адрес на сървър, отдалечен ID, акаунт или сертификат и незадължителни правила за свързване при поискване. Запазването на този запис съхранява връзка в мрежовата конфигурация на вашия Mac. Нищо в процеса не завързва порт, не отваря слушател и не регистрира отдалечен потребител.

Можете да проверите това от шела. На Mac, за който подозирате, че обслужва, изпълнете sudo lsof -nP -iUDP и потърсете портовете, които ползва вашият протокол: 500 и 4500 за IKEv2, 1194 за стандартния OpenVPN, 51820 за WireGuard. Машина само с клиент показва сокети, свързани с отдалечен адрес и порт, а не обвързване с шаблон, до което нещо в интернет би могло да стигне. Тунелите, които работят в Network Extension, могат да се скрият от lsof, затова при всички случаи сверявайте и собствения панел за състояние на приложението; това, което няма да намерите, е предпочитание на Apple, което превръща този Mac в шлюз.

Три въпроса разделят двете роли

Минете през тях по ред. Първият обикновено решава останалото, а третият е мястото, където повечето планиране, специфично за Mac, се обърква.

1. Кой започва разговора? Ако вашият Mac се свързва навън и другата страна отговаря, трябва ви клиент. Ако устройства в интернет трябва да се свързват навътре, за да стигнат до мрежата ви, трябва ви шлюз с публична входна точка и Mac може да остане клиент на този шлюз.

2. Какво трябва да е достъпно, докато тунелът е включен? Една услуга на един хост е решение за пренасочване на порт. Цяла подмрежа, включително разрешаването на имена, е решение за маршрутизиране и DNS и то променя това, което шлюзът трябва да пренасочва, а не това, което казва записът за клиент.

3. Коя версия на ОС работи на приемащата страна? За Mac този въпрос има твърд отговор. Apple посочва VPN като премахнат от macOS Server 5.7.1, а самото приложение macOS Server беше прекратено на 21 април 2022 г.; страницата, която си струва да прочетете, когато стар урок ви превежда през отметка за VPN услуга, която вече не съществува, е съобщението за историята на услугата.

Когато първият отговор е “някой отвън започва”, спрете да търсите ключ в клиентския панел на Mac и изберете хоста, който ще прекрати тунела.

Къде вместо това може да живее шлюзът

Четири подредби покриват повечето домашни и малки офисни случаи. Рутер с истински сървърен режим, за разлика от клиентски режим с различен етикет, прекратява тунела на ръба и държи броя на хостовете нисък, с цената на обвързване с поддръжката на протоколи на този фърмуер. NAS или мини компютър, който работи постоянно, пуска сървърния пакет на производителя и ви оставя логове, които можете да четете. Малка облачна VM ви дава публичен адрес, който контролирате, и стига до вкъщи през втори тунел. Мрежа тип mesh, изградена върху WireGuard, или управлявана услуга, която препредава между партньори, заобикаля пренасочването на входящи портове, като кара двата края да се свързват навън.

Границата между тези опции обикновено е интернет връзката ви, а не софтуерът. Ако доставчикът ви поставя зад NAT на ниво оператор, никакво пренасочване на портове на рутера не създава достъпна входна точка и честният отговор е подредба с релей или mesh. Сравнете WAN адреса, който рутерът ви съобщава, с адреса, който външният свят вижда; ако се различават и стойността на рутера е в частен или споделен диапазон, планирайте случая с релей.

Който и хост да изберете, пренасочвайте един протокол на един порт, а не диапазон, и дръжте Mac извън входящия път, освен ако точно този продукт не документира сървърна роля за версията на macOS, която ползвате.

Потвърдете ролята, преди да раздавате профили

На кандидат шлюза докажете, че слушател съществува, вместо да вярвате, че инсталаторът е създал такъв. На macOS това означава sudo lsof -nP -iUDP, филтриран до портовете по-горе, плюс sudo pfctl -s nat, ако правилата на пакетния филтър са част от дизайна. На Linux ss -lunp показва същите факти без двусмислие.

След това тествайте отвън мрежата, използвайки самия протокол. Ping доказва малко: ICMP обикновено се филтрира и не казва нищо за UDP 51820. Клиентски ръкостиск с подробно логване, пуснат от телефон на мобилни данни, е най-евтиният реален тест, защото минава по същия път, по който ще мине отдалечен колега.

Едва след това пипайте клиентските профили. На Mac scutil --nc list отпечатва VPN услугите, които системата познава; ако шлюзът, който току-що построихте, не е сред тях, конфигурирате друга машина, различна от тази, която тествахте. Ако ръкостискът успее в локалната мрежа, но се провали отвън, причината е във входящия път: NAT правило, CGNAT на доставчика или защитна стена на шлюза, точно в този ред.

Преди да построите каквото и да е, решете четири точки:

• Коя страна започва връзката, вашият Mac или отдалечено устройство.
• Дали версията на ОС и продуктът на приемащия хост наистина поддържат сървърна роля.
• Дали доставчикът ви дава изобщо достъпен публичен адрес.
• Кой единствен порт и протокол ще приема шлюзът и коя услуга зад него отговаря.

Следващата стъпка е конкретна: изберете хост шлюза, потвърдете слушателя му отвън и само след това създайте записа за клиент на Mac, който сочи към него.