vpn пишет «подключено». через него вообще что-нибудь идёт?

работает ли vpn: три команды, одна минута

vpn может быть «подключён» и не нести ничего, нести половину вашего трафика или нести всё, пока dns по-прежнему ходит к провайдеру. слово в клиенте покрывает любой из случаев. macOS знает, в каком вы, и говорит об этом в трёх местах.

1. route -n get default. строка interface называет дверь, через которую уходит трафик. utun7 (любой номер utun) — это туннель; en0 — Wi-Fi или кабель, и по умолчанию не туннелируется ничего. netstat -rn -f inet показывает то же самое: две строки default, utun и en0, и побеждает первая.
2. scutil --nc list даст имя туннеля и его состояние; потом scutil --nc statistics "name", подождите пять секунд и выполните ещё раз. BytesIn должен расти; здесь за эти пять секунд вышло 154 447 263 → 154 763 044. счётчики стоят на месте — туннель поднят и пуст.
3. curl https://api.ipify.org печатает адрес, который видит остальной интернет. он должен принадлежать провайдеру vpn, а не вашему домашнему. любая страница «какой у меня ip» в браузере делает то же самое; вариант из «Терминала» просто нельзя сбить сохранённой сессией.

все ключи scutil --nc, прямо из руководства (страница английская): scutil(8)

что на самом деле значит «подключено» в клиенте

scutil --nc status "name" печатает Connected и для туннеля, который за эту минуту перенёс тридцать мегабайт, и для того, который умер час назад. поля «несёт трафик» там нет вовсе: состояние описывает момент, когда туннель договорился о соединении, и клиент показывает то же слово, потому что спрашивает у той же системы.

ifconfig расставляет ловушку: Mac держит несколько интерфейсов utun независимо от любого vpn (здесь восемь, от utun0 до utun7), и адрес inet есть только у одного. вот он и есть туннель; семь без адреса — это не семь vpn.

vpn подключён, а ip не поменялся: куда ушёл трафик вместо туннеля

если маршрут по умолчанию на en0, а клиент пишет «подключено», значит туннель поднялся и маршрут себе не забрал. он не сломан — ему просто не велели нести всё. какой переключатель за это отвечает, зависит от типа vpn.

1. у встроенной конфигурации L2TP переключатель лежит в системных настройках: раздел VPN → кнопка «i» рядом со службой → дополнительные параметры → отправлять весь трафик через vpn-соединение. Apple пишет, что этот параметр есть только у L2TP поверх IPSec: у остальных типов маршруты диктует сервер при установлении соединения, и включать на своей стороне нечего.
2. у клиента со своим приложением — а это большинство — ищите в его настройках «split tunnelling», исключения для приложений или обход. раздельное туннелирование и есть подключённый vpn, у которого маршрут по умолчанию намеренно оставлен на en0, и ip у вас не меняется по замыслу.
3. если ваш настоящий адрес видит один конкретный сайт, спрашивайте про него: route -n get example.com называет интерфейс для одного этого адреса — это и есть ответ, когда маршрут по умолчанию в порядке, а утекает один узел.

о самом параметре и о том, у каких типов vpn он есть, — у Apple (страница английская): параметры vpn-соединений l2tp поверх ipsec на Mac

маршруты, которые рабочий vpn намеренно оставляет снаружи

у scutil --nc status "name" есть блок ExcludedRoutes. на этом Mac в нём перечислены 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 против en0 — частные диапазоны. route -n get 192.168.50.1 подтверждает: до роутера ходят по Wi-Fi, а не через туннель. поэтому при поднятом vpn принтер продолжает печатать, и это не утечка: адрес из этих диапазонов, уходящий через en0, — это конфигурация делает ровно то, что в ней написано.

а dns идёт через vpn?

внешний адрес может быть правильным, пока каждое имя вам по-прежнему разрешает провайдер. решает это scutil --dns: resolver #1 должен быть сервером имён туннеля, а его if_index — указывать на интерфейс utun; здесь это nameserver[0] : 198.18.0.2, if_index : 25 (utun7). если при поднятом туннеле resolver #1 — ваш роутер на en0, имена уходят мимо, и чинить это клиенту: настройку dns он должен был отдать и не отдал.

второй тихий выход — ipv6. многие туннели несут только ipv4; если сеть выдаёт маршрутизируемый адрес ipv6, сайты, которые его предпочитают, приходят к вам через en0. route -n get -inet6 default говорит, есть ли вообще маршрут ipv6 по умолчанию — здесь у Wi-Fi только link-local, ответ «not in table», и беспокоиться не о чем.

когда разовой проверки хватает, а когда она перестаёт помогать

перед одной важной сессией — банк, рабочая шара — три команды выше и есть весь ответ. выполните их, прочитайте utun и чужой адрес, работайте дальше.

хватать перестаёт в тот момент, когда это приходится повторять: туннель, несший трафик в девять, не обязан нести его в одиннадцать, а клиент в обоих случаях пишет «подключено». бесплатный путь берёт не деньгами, а вниманием: вы должны вспомнить, что их надо выполнить, — каждый раз, когда засомневались.

как hop показывает, несёт ли vpn трафик

hop перечисляет все vpn, о которых знает ваш Mac, и даёт каждому переключатель. список читается из системных настроек, поэтому какой бы клиент вы ни поставили, он уже там. пока туннель поднят, на значке в строке меню стоит маленькая точка.

• зелёная — туннель поднят. пока он поднимается или опускается, точка гаснет.
• оранжевая — туннель включён, а обратно через него ничего не возвращается. это вторая из команд выше, работающая весь день при закрытой панели.
• панель помечает строку, о которой речь, — так что при нескольких конфигурациях видно, какая именно замолчала.

сам переключатель и что он ещё делает со списком туннелей: переключатель vpn

туннель держит macOS, а не hop, поэтому выход из приложения с вашим соединением не делает ничего. нажатие на название открывает окно самого vpn — на те случаи, когда оно нужно. точку можно выключить в настройках, переключатели продолжат работать и без неё.

если vpn всё равно не несёт ваш трафик

• страница с ip показывает ваш город, а route говорит utun. посмотрите, что меряет страница: сайт мог запомнить вас ещё до поднятия туннеля, или в Safari включено «Частный узел iCloud» — он отдаёт сайтам свой временный адрес, поэтому его ответ не про ваш vpn. у curl из «Терминала» нет ни того, ни другого.
• маршрут по умолчанию на utun, а BytesIn с места не двигается. туннель поднят и пуст: отключите и подключите его заново, а если это происходит ежедневно, туннель умирает не случайно, а вместе со сном.
• два клиента, установленные разом, делят между собой таблицу маршрутов, и «подключено» у проигравшего — неправда. тот, которым вы больше не пользуетесь, удалите как следует, вместе с тем, что он оставил.
• маршрут возвращается на en0 через несколько секунд после каждого подключения. таблицу маршрутов переписывает кто-то ещё: второй vpn, файрвол, прокси-утилита. выключайте их по одному и после каждого выполняйте route -n get default.

что «Частный узел» делает с адресом, который видит сайт, — у Apple (страница английская): о «Частном узле iCloud»

как люди описывают этот симптом своими словами, на Apple Community (страница английская): vpn подключён, а трафик идёт напрямую

то, чем это делается: удаление приложений

frequently asked questions

как проверить, работает ли vpn на Mac?

route -n get default в «Терминале»: utun с номером — трафик уходит через туннель, en0 — не уходит. потом curl https://api.ipify.org; адрес должен быть провайдера vpn, а не вашего домашнего. на обе команды меньше минуты.

как понять, что трафик действительно идёт через vpn?

маршрут говорит, куда пакеты отправляют, счётчики — двигается ли хоть что-то. scutil --nc statistics "name" дважды с паузой в несколько секунд: растущий BytesIn означает, что туннель несёт трафик. стоящие счётчики при маршруте по умолчанию на utun означают, что туннель поднят и пуст.

почему vpn пишет «подключено», а ip не поменялся?

туннель поднят, а маршрут по умолчанию не на нём. у встроенной конфигурации L2TP за это отвечает параметр «отправлять весь трафик через vpn-соединение»; у других типов маршруты приходят с сервера, а у клиента-приложения это обычно настройка раздельного туннелирования. с какого случая начинать, скажет route -n get default.

значок vpn в строке меню означает, что трафик через него идёт?

значок самого клиента означает, что туннель установлен. идёт ли через него что-нибудь сейчас, он не проверяет. точка hop — как раз исключение, ради которого она и сделана: зелёная, пока туннель поднят, и оранжевая, когда он поднят, а обратно через него ничего не возвращается.

как проверить утечку dns на Mac?

scutil --dns и смотреть на resolver #1. при поднятом туннеле это должен быть сервер имён самого vpn, привязанный к интерфейсу utun через if_index. если первый resolver — ваш роутер на en0, имена разрешаются снаружи туннеля, хотя страницы идут внутри него.

при включённом vpn принтер и домашний диск всё ещё работают — это утечка?

обычно нет. scutil --nc status печатает блок ExcludedRoutes, и частные диапазоны (10/8, 172.16/12, 192.168/16) в нём нарочно перечислены против en0. трафик к собственной сети, остающийся на Wi-Fi, — это конфигурация, а не неисправность.

проверяет ли hop мой ip или dns?

нет. hop показывает про туннель, который держит система, две вещи: что он поднят и возвращается ли через него хоть что-нибудь. и ещё его переключает. внешний адрес и резолвер — это две команды выше, и они остаются на вас.

the tool behind this

done with vpn

other things people do

• your vpn says connected. nothing loads.vpn switcher
• the Mac woke up. the tunnel did not.vpn switcher
• no built-in way to see how hot your Mac issystem monitor