Разделени маршрути L2TP на Mac: защо адресът на хост не работи

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

Дестинацията е адрес на мрежа, маската описва префикса

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 тунелите се нуждаят от hook, а не от ключ

За тунели на базата на PPP defaultroute е ключът в профила, който създава маршрут по подразбиране; премахнете го и клиентът спира да претендира за всяка дестинация. След това маршрутите се добавят, след като интерфейсът се появи, обикновено от /etc/ppp/ip-up:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

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

Проверете разделянето с три заявки

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

Завършете с три заявки, които доказват разделянето: един вътрешен хост по адрес, едно вътрешно име през вътрешния резолвер и един публичен сайт, който все още трябва да използва локалната връзка. Ако публичният сайт сега също минава през тунела, разделянето никога не се е случило, каквото и да изглежда, че казва списъкът с маршрути.

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