Налады VPN на Mac не запускаюць сервер: дзе жыве шлюз

У macOS два розныя заняткі носяць назву VPN, і панэль налад займаецца толькі адным з іх. Калі вы хочаце, каб трафік гэтага 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 або міні-ПК, які заўсёды ўключаны, запускае серверны пакет вытворцы і пакідае вам журналы, якія можна чытаць. Невялікая хмарная ВМ дае вам публічны адрас, які вы кантралюеце, і дабіраецца дадому праз другі тунель. Сетка-меш на аснове WireGuard або кіраваная служба, якая перадае паміж аднаранговымі вузламі, абыходзіць перанакіраванне ўваходных партоў тым, што абодва бакі злучаюцца вонкава.

Мяжа паміж гэтымі варыянтамі — звычайна ваша інтэрнэт-злучэнне, а не праграмнае забеспячэнне. Калі правайдэр змяшчае вас за NAT аператарскага ўзроўню, ніякая колькасць перанакіраванняў портаў на маршрутызатары не стварыць дасягальнага пункта ўваходу, і сумленны адказ — перадача праз пасрэдніка або меш. Параўнайце 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, які паказвае на яго.