Постоянни маршрути за Mac VPN: networksetup или hook при свързване?

Маршрут, въведен след всяка връзка, решава момента, а не седмицата. В macOS трайният избор обикновено е префикс, съхранен с VPN услугата, защото услугата го преинсталира при всяко свързване и го премахва, когато услугата е спряна. Алтернативите са временен route add за тестване и hook при свързване за адреси, които са известни само след договаряне.

Решете дали маршрутът принадлежи на услугата или на сесията

Попитайте от какво зависи префиксът. Ако това е фиксирана частна мрежа зад нативна VPN услуга, маршрутът принадлежи на тази услуга. Ако зависи от адрес на партньор, който се променя при всяка връзка, hook или задача, управлявана от състояние, може да е по-добрият собственик. Ако само проверявате път за следващите пет минути, временният маршрут е достатъчен.

Маршрутът, обвързан с услугата, има най-чист жизнен цикъл. Появява се с услугата и изчезва, когато услугата не е свързана, така че не може да надживее тунела, към който сочи. Това свойство струва повече от удобството на еднократна команда.

Маршрутът, обвързан със сесията, принадлежи на интерфейса и този номер се променя без предупреждение. Повторно свързване може да даде на тунела различно име utun от предишната сесия, което превръща твърдо зададена команда в маршрут, който не сочи никъде или, по-лошо, към друг тунел.

Прочетете текущото състояние на маршрута и услугата

Започнете с имената, които системата наистина използва. Името на услугата в настройките на мрежата е идентификаторът за командите по-долу, а текущата таблица на маршрутите показва какво е инсталирал свързаният клиент. Прочетете и двете, докато тунелът е активен.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Тази проверка показва кой шлюз и интерфейс би избрало ядрото за този адрес в този момент. Ако вече избира тунела, префиксът е покрит и нов маршрут би бил излишен. Ако избира локалния рутер, на тунела липсва този префикс.

Отбележете адреса на партньора, докато сте свързани. Той става стойност на шлюза в маршрута, обвързан с услугата, и обикновено е дестинацията, показана за маршрута по подразбиране на тунела в netstat -rn.

Съхранете префикса с networksetup

Инструментът networksetup прикачва допълнителни маршрути към мрежова услуга. За услуга с име OfficeVPN и частен префикс, достигнат през партньора на тунела, формата е:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Всяка тройка след името на услугата дава дестинация, нейната мрежова маска и партньора на тунела като шлюз. Едно извикване може да носи няколко префикса, а празно извикване изчиства съхранения списък. Четецът е стъпката за проверка; ако списъкът е празен, настройката не се е приложила към услугата, за която мислите.

Шлюзът трябва да е партньорът на тунела, а не физическият рутер. Маршрут, който посочва локалния шлюз, изпраща частния префикс през физическия интерфейс, което е първоначалният отказ с допълнителни стъпки. Остарелият партньор е най-честата причина правилно изглеждащ маршрут никога да не носи трафик. Препрочетете партньора от свързаното състояние, вместо да копирате адрес от стара бележка.

Използвайте route add само за тест

Директният маршрут е полезен, за да докаже, че префиксът работи, преди да го направите постоянен. Формата с интерфейс избягва търсене на шлюз:

sudo route -n add -net 10.20.0.0/16 -interface utun4

Маршрутът изчезва при следващото свързване и зависи от номера на интерфейса, който съществува днес. Това го прави диагностика, не внедряване. Ако тестът работи, а маршрутът, обвързан с услугата, не, първо сравнете стойността на шлюза; това е полето, което най-често е грешно.

Внимавайте със съвети, които заместват маршрута по подразбиране на VPN, за да наложат разделяне. Клиент, който налага пълен тунел, може да преинсталира маршрутите си след повторно свързване или обновяване на политика, така че ръчната промяна се отменя тихо. Няколко частни префикса са проблем с маршрутизацията; задържането на целия интернет трафик локално срещу политика за пълен тунел е решение от страна на сървъра.

Изберете hook само когато адресът се договаря

За връзки на базата на PPP, като L2TP, macOS изпълнява /etc/ppp/ip-up след установяване на връзката. Скриптът получава името на интерфейса и договорените локален и отдалечен адрес, така че може да добави маршрут, който зависи от партньора, зададен от сървъра. Това е точно случаят, който фиксиран маршрут на услуга не може да изрази.

IKEv2 и клиенти на доставчици може изобщо да не използват този PPP път, което означава, че скриптът може да остане безмълвен през цялата сесия. Когато това се случи, задача на launchd, която опитва scutil --nc status и реагира на промяна на състоянието, е еквивалентният механизъм, с малко закъснение.

Който и hook да използвате, направете го идемпотентен и нека премахва само маршрутите, които е създал. Скрипт, който изтрива всеки маршрут, споменаващ тунела, в крайна сметка ще изтрие маршрута, който поддържа VPN сървъра достъпен, и връзката ще падне веднага щом успее.

Завършете, като проверите частната дестинация, обичайното сърфиране и цикъл на повторно свързване или сън. След това инспектирайте scutil --dns, защото разрешаването на имена е отделна политика и работещ маршрут не доказва, че частните имена се разрешават.