Mac VPN повезан, али ip-up се никада није покренуо: поставите launchd надзор

Тунели Cisco IPSec и IKEv2 никада не покрећу pppd, па /etc/ppp/ip-up остаје тих. Надгледајте фасциклу конфигурације и натерајте скрипту да докаже тунел.

Ставите наредбу route у /etc/ppp/ip-up, поново повежете канцеларијски тунел, а датотека се никада не изврши. Са скриптом није ништа погрешно: та веза уопште не пролази кроз PPP. Уграђени клијенти Cisco IPSec и IKEv2 никада не покрећу pppd, па се фасцикла кука никада не чита, док PPTP и L2TP преко IPSec-а и даље пролазе кроз њу. Утврдите који је случај код вас, а затим покрените не-PPP случај из задатка надзора launchd.

Проверите интерфејс пре него што уредите било коју куку

Две наредбе одређују који механизам може да ради. Наведите конфигурисане услуге, затим наведите интерфејсе који постоје док је тунел активан. Назив интерфејса је доказ; ознака у системским подешавањима није.

scutil --nc list
ifconfig -l | tr ' ' '\n' | grep -E '^(utun|ppp)[0-9]+$'

Услуга која ствара ppp0 извршава PPP куке и извршиће вашу датотеку. Услуга Cisco IPSec или IKEv2 уместо тога ствара уређај utun, интерфејс тунела без PPP слоја, па ништа унутар /etc/ppp не може да га достигне. Када се појаве обе врсте, проверите на коју услугу сте се повезали. Људи изгубе поподне на погрешној куки читајући назив клијента.

На PPP путу датотека мора бити у власништву root-а и извршна, јер pppd проверава обоје пре него што било шта покрене. install поставља власника и режим у једном кораку.

sudo install -o root -g wheel -m 0755 /dev/null /etc/ppp/ip-up
sudo ls -l /etc/ppp/ip-up

Датотека створена преко Finder-а или графичког уређивача често заврши у власништву вашег налога или без бита за извршавање, а затим не успе тако тихо као кука која је недостајала. Ставите ip-down поред ње сада. root и wheel у колони власника плус rwxr-xr-x у колони режима је оно што желите.

Дозволите launchd-у да покрене скрипту када се тунел појави

За клијенте који никада не дотичу PPP, окидач мора да дође са другог места, а складиште системске конфигурације је поштен извор: macOS га преписује при сваком прелазу тунела. Задатак launchd-а који надгледа ту фасциклу се позива када се тунел појави или нестане.

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>WatchPaths</key>
  <array><string>/Library/Preferences/SystemConfiguration</string></array>
  <key>Label</key><string>net.example.tunnel-watch</string>
  <key>ProgramArguments</key>
  <array><string>/bin/sh</string><string>/usr/local/sbin/tunnel-hook</string></array>
  <key>RunAtLoad</key><true/>
  <key>ThrottleInterval</key><integer>20</integer>
</dict>
</plist>

Инсталирајте га као launch daemon, а не као агента по кориснику, јер поправка путања припада машини. bootstrap замењује старији облик load -w у текућим издањима. RunAtLoad чини прво извршавање видљивим, а ThrottleInterval спречава да налет промена при повезивању на Wi-Fi више пута покрене скрипту.

sudo install -o root -g wheel -m 0644 tunnel-watch.plist \
  /Library/LaunchDaemons/net.example.tunnel-watch.plist
sudo launchctl bootstrap system \
  /Library/LaunchDaemons/net.example.tunnel-watch.plist

Замка је у томе што се надгледана фасцикла мења и због догађаја који немају везе са вашим VPN-ом: повезивање на Wi-Fi, обнова DHCP-а, прикључен кабл. Чувар испод претвара бучни окидач у употребљиву куку, а ред у дневнику објашњава путању у необичан сат.

Власништво покрива plist као и скрипту. Демон који извршава датотеку у фасцикли у коју ваш налог може да пише даје том налогу root.

Заштитите скрипту тако да друго покретање ништа не промени

Скрипта прво одлучује да ли тунел постоји и тихо излази када не постоји. Све после тога мора бити безбедно за понављање, јер се окидач активира много чешће од једне везе. Решите интерфејс у време извршавања уместо да тврдо кодирате индекс који се мења при следећем повезивању.

#!/bin/sh
set -u
TUN=$(ifconfig -l | tr ' ' '\n' | grep -m1 '^utun[0-9]' || true)
[ -n "$TUN" ] || exit 0
netstat -rn -f inet | grep -q '^10\.42' && exit 0
route -n add -net 10.42.0.0/16 -interface "$TUN"

route add излази са ненултим статусом када путања већ постоји, па скрипта која сваки ненулти статус третира као грешку пријављује сломљену куку сваки пут када ради исправно. Тест са netstat изнад претвара тај случај у експлицитан no-op.

Присуство интерфејса је слабији доказ него што изгледа, јер и други VPN клијенти и нека контејнерска окружења стварају уређаје utun. Питајте саму услугу преко scutil --nc status "Office VPN" и захтевајте повезано стање пре него што дотакнете рутирање. Држите одговор у реду дневника, јер ће недељу дана касније тај запис бити једино објашњење које имате.

Вратите мрежни пролаз без ломљења DNS-а

Када тунел преузме подразумевану путању, обично прегледање излази кроз канцеларију и локална интернет путања престаје да ради. Прво ухватите рутер физичког интерфејса, затим усмерите подразумевану путању назад на њега. DHCP је бољи од рашчлањивања табеле која већ садржи сопствену подразумевану путању тунела.

PHYS=en0
GW=$(ipconfig getoption "$PHYS" router)
[ -n "$GW" ] && sudo route -n change default "$GW"

Резолвери су засебан слој са засебним алатом и поправка путање их не поправља. Погледајте помоћу scutil --dns шта важи, затим поправите оно што то ствара: редослед услуга и DNS записе на физичкој услузи. Пражњење кеша дијагностикује претрагу заглављену после промене мреже; то није нешто што се заказује.

Тунел који преживи промену Wi-Fi-ја док DNS стане је трећа грешка: sudo killall -HUP mDNSResponder тера резолвер да поново прочита конфигурацију. Употребите га једном, ручно.

Докажите да се задатак сам активира

Присилно покрените једном помоћу kickstart -k пре него што поверите путањи надзора, а затим прочитајте излазни статус који је задатак забележио. Чист излаз доказује да скрипта ради; не доказује да окидач ради. Затим се искључите и поново повежите са учитаним задатком и гледајте извршавање које нисте тражили.

sudo launchctl kickstart -k system/net.example.tunnel-watch
sudo launchctl print system/net.example.tunnel-watch | grep -E 'last exit code|state ='

Проверите scutil --nc status пре и после сваког покушаја. Скрипта која је радила док је тунел био спуштен не доказује ништа о путу повезивања.

Грана за растављање заслужује исти третман као грана за повезивање: уклоните путању ручно, пустите задатак да ради и потврдите да се враћа. Кука која додаје путању и никада је не уклања оставља машину која се понаша лоше недељу дана касније, без ичега што повезује два догађаја. Када оба понашања важе, sudo launchctl bootout system/net.example.tunnel-watch чисто пензионише задатак. Демон надзора остављен учитан је начин на који једнократна поправка месецима касније постаје необјашњена путања.

Повезани чланци