Раздзеленыя маршруты L2TP на Mac: чаму адрас хоста не працуе
setadditionalroutes патрабуе пары сеткі і маскі, замяняе ўвесь спіс і патрабуе дакладнага імя службы. Праверце табліцу, перш чым вінаваціць шлюз.
VPN падключаецца, радок меню паказвае гэта, а ўнутраны хост усё роўна не адказвае. У такой сітуацыі ёсць тры магчымыя прычыны, і якая з іх дзейнічае, залежыць ад таго, як быў наладжаны тунель. Або каманда маршруту выкарыстала адрас хоста там, дзе патрабаваўся адрас сеткі, або сам профіль усталёўвае маршрут па змаўчанні, які праглынае рашэнне, або кліент — гэта тунель PPP, якому патрэбны хук, а не ключ профілю. Праверце іх у гэтым парадку, бо першую прычыну прасцей за ўсё выключыць.
Прызначэнне — гэта адрас сеткі, маска апісвае прэфікс
networksetup -setadditionalroutes прымае тройкі з прызначэння, маскі падсеткі і шлюза. Выклік, які накіроўвае адну ўнутраную падсетку праз тунель, выглядае так:
sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0
Звярніце ўвагу, што такое прызначэнне: адрас сеткі, а не адрас сервера, да якога вы імкнецеся. У выпадку, які спарадзіў гэты артыкул, ідэнтычная каманда з 192.168.1.20 на гэтым месцы не зрабіла нічога карыснага, а замена яго на 192.168.1.0 спрацавала адразу. Тая ж маска, той жа шлюз, адзін іншы лік. Гэта і ёсць уся памылка ў мініяцюры.
Прычына — арыфметыка, а не палітыка. Адрас хоста ў пары з маскай /24 не апісвае 192.168.1.0/24; ён апісвае нешта, што табліца маршрутызацыі не можа карысна ўтрымаць, таму запіс адхіляецца або ігнаруецца, і тунель у выніку нясе менш, чым вы планавалі.
Калі вам патрэбен роўна адзін хост, выкарыстоўвайце адрас хоста з маскай 255.255.255.255. Памылка ў змяшаных парах, а не ў выкарыстанні адраса хоста як такога. /32, пабудаваны з аднаго адраса, — гэта законны маршрут; /24, пабудаваны з аднаго адраса, — гэта памылка.
Выклік замяняе спіс, а імя — літаральнае
Дзве паводзіны здзіўляюць людзей пры першай спробе. Каманда ўсталёўвае поўны спіс дадатковых маршрутаў, а не дадае да яго, таму выклік, які дадае адзін прэфікс, моўчкі выдаляе іншыя, што былі раней. Будуйце ўвесь набор адным выклікам.
Імя службы таксама не той ярлык, які вы прыдумалі. Прачытайце яго з інструмента і скапіруйце дакладна, уключаючы суфікс тыпу:
networksetup -listallnetworkservices
Імя, якое адрозніваецца на адзін сімвал, не дае ні памылкі, вартай чытання, ні маршруту. Капіраванне і ўстаўка — правільная тэхніка тут, а не перадрукоўванне з памяці.
Калі профіль займае маршрут па змаўчанні
Раздзеленыя маршруты саступаюць маршруту па змаўчанні для любога прызначэння, якое яны не пакрываюць яўна, а профіль L2TP, настроены на поўны тунель, усталёўвае менавіта гэта. Калі профіль кажа, што ўсё ідзе праз тунель, спіс дадатковых маршрутаў змяняецца вельмі мала. Ваш запіс не памылковы; ён проста не мае дачынення да прызначэнняў, якія ён ніколі не называе. Кіраванне гэтым звычайна знаходзіцца ў наладзе профілю «адпраўляць увесь трафік», а не ў якой-небудзь камандзе маршруту.
Вырашыце, якую мадэль вы насамрэч хочаце, перш чым рэдагаваць яшчэ запісы. Поўны тунель з выключэннямі — гэта іншая канфігурацыя, чым раздзелены тунель з пэўнымі прэфіксамі, і змешванне двух дае табліцу, якую ніхто не можа прадказаць.
Калі арганізацыя патрабуе поўнага тунелю, спыніце спробы раздзяліць яго лакальна і перанясіце патрабаванне таму, хто валодае палітыкай. Лакальна дададзены маршрут, які ёй супярэчыць, будзе выдалены наступным абнаўленнем профілю ў любым выпадку.
Тунелям PPP патрэбны хук замест ключа
Для тунеляў на базе PPP defaultroute — гэта ключ профілю, які стварае маршрут па змаўчанні; прыбярыце яго, і кліент перастане заяўляць кожнае прызначэнне. Затым маршруты дадаюцца пасля з'яўлення інтэрфейса, звычайна з /etc/ppp/ip-up:
#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0
Трымайце скрыпт ва ўласнасці root і выканальным, і дадайце ахову на імя інтэрфейса, калі на машыне ёсць больш за адзін профіль тунелю. Хук, які запускаецца для кожнага злучэння PPP і мяркуе адно імя прылады, — гэта маленькая памылка з доўгім жыццём.
Праверце раздзяленне трыма запытамі
Здыміце табліцу, пакуль падключаны, і адзначце, які інтэрфейс абслугоўвае тунель. Затым праверце канкрэтнае прызначэнне, а не давярайце статусу выхаду каманды, якая яго стварыла. Код выхаду паведамляе, ці інструмент прыняў аргументы, а не ці трафік ідзе па шляху, які вы мелі на ўвазе.
Скончыце трыма запытамі, якія даказваюць раздзяленне: адзін унутраны хост па адрасе, адно ўнутранае імя праз унутраны рэзалвер і адзін публічны сайт, які павінен па-ранейшаму выкарыстоўваць лакальнае злучэнне. Калі публічны сайт цяпер таксама ідзе праз тунель, раздзялення не было, што б ні казаў спіс маршрутаў.
Падключыцеся яшчэ раз і паўтарыце ўнутраны запыт, бо маршруты, дададзеныя ўручную, могуць перажыць інтэрфейс, які зрабіў іх сапраўднымі і моўчкі кідаюць трафік у чорную дзірку пасля падзення тунеля.