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

Ставате наредба 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 чисто ја пензионира задачата. Оставен вчитан демон за надзор е патот на кој еднократна поправка станува необјаснета рута месеци подоцна.