Mac VPN-поставките не стартуваат сервер: каде живее портата

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

Записот за клиент именува цел, а не слушач

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

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

Три прашања ги делат двете улоги

Поминете ги по ред. Првото обично го решава останатото, а третото е местото каде најмногу греши планирањето специфично за Mac.

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

2. Што мора да биде достапно додека тунелот е кренат? Една услуга на еден домаќин е одлука за препраќање порти. Цела подмрежа, вклучително и разрешувањето имиња, е одлука за рутирање и DNS, и таа менува што портата мора да препрати, а не што вели записот за клиент.

3. Кое издание на OS го извршува прифатниот крај? За Mac-овите тоа прашање има цврст одговор. Apple го наведува VPN како отстранет од macOS Server 5.7.1, а самата апликација macOS Server беше прекината на 21 април 2022; известувањето за историјата на услугата е страницата што треба да се прочита кога стар прирачник ве води низ поле за VPN-услуга што повеќе не постои.

Кога првиот одговор е „некој однадвор започнува“, престанете да барате прекинувач во панелот за клиент на Mac и одете да го изберете домаќинот што ќе го заврши тунелот.

Каде портата може да живее наместо тоа

Четири поставености покриваат повеќето домашни и мали канцелариски случаи. Рутер со вистински серверски режим, наместо клиентски режим со друга ознака, го завршува тунелот на работ и го држи бројот на домаќини низок, но по цена да бидете врзани за протоколната поддршка на тој firmware. 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-услугите што системот ги знае; ако портата што штотуку ја изградивте не е меѓу нив, конфигурирате друга машина од онаа што ја тестиравте. Ако ракувањето успее на LAN, но не успее однадвор, грешката е во влезната патека: NAT-правило, CGNAT на давателот или firewall на портата, по тој ред.

Пред да изградите нешто, решете четири точки:

• Која страна ја започнува врската, вашиот Mac или оддалечен уред.
• Дали изданието на OS и производот на прифатниот домаќин навистина поддржуваат серверска улога.
• Дали давателот воопшто ви дава достапна јавна адреса.
• Која единствена порта и протокол ќе ги прифати портата и која услуга зад неа одговара.

Следниот чекор е конкретен: изберете го домаќинот на портата, потврдете го неговиот слушач однадвор и само тогаш создајте го записот за клиент на Mac што покажува кон неа.