Тунелът се вдига, иконата става зелена и локалната мрежа изчезва: принтерите, NAS и офис рутерът спират да отговарят. FortiClient прави това, което профилът е поискал. Шлюзът изпрати маршрут по подразбиране, клиентът го инсталира и сега всеки пакет има път в тунела. Поправката е редакция на таблицата с маршрути с редакция на DNS зад нея, а редът на тези редакции решава дали машината ще излезе по-добре или по-зле.

Какво инсталира клиентът и защо LAN изчезна

Започнете с четене на таблицата, вместо с интерфейса на клиента. В macOS netstat -rn отпечатва цялата таблица, а route -n get default посочва интерфейса и метриката, които в момента печелят; в Linux двойката е ip route show и ip route get 8.8.8.8. И двете отговарят на един въпрос: кой запис ще пренесе пакет, който не съвпада с нищо по-конкретно.

Името на тунелното устройство не е фиксирано. Профил IKEv2 в macOS обикновено показва utun с номер, клиентът SSL VPN показва ppp0, а OpenVPN показва tun0. Възможно е и две маршрути по подразбиране да присъстват едновременно с различни метрики, а записът на клиента може да поеме едва след повторно свързване, а не в момента на появяване. Затова две изтегляния на таблицата, направени пет минути едно от друго, могат да разказват различни истории.

Защо тунелният маршрут по подразбиране трябва да си отиде първи

Ядрото избира най-дългия съвпадащ префикс, а когато няколко маршрута са еднакво конкретни, избира този с най-ниска метрика. Затова клиент, който инсталира 0.0.0.0/0 с по-добра метрика, печели всяка дестинация, без да изтрива оригиналния маршрут по подразбиране; ето защо физическият маршрут все още е в таблицата и все още обяснява прекъсването. Премахването на тунелния маршрут по подразбиране първо възстановява предишното поведение. Само след това префиксен маршрут през тунела прави това, което авторът му е имал предвид.

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

Последователността в macOS и в Linux

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

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

В Linux същият ред използва различен инструмент: LAN шлюза за маршрута по подразбиране и тунелното устройство за офис префикса. Старата команда route все още приема стария синтаксис, но ip route е формата, която отговаря на текущата документация.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Когато маршрутът се нуждае от следващ хоп, а не от устройство, вземете peer от изхода на клиента. Предположението дава една от две грешки и те означават различно: грешен шлюз дава network unreachable веднага, докато грешна тунелна цел дава таймаут. Прочетете коя получихте, преди да промените командата отново.

Префикси, резолверът и DMZ, която остава тъмна

Един префикс рядко покрива работата. Сървърите за приложения, мрежите за управление, DMZ и самите DNS сървъри могат да са в различни диапазони, затова избройте всеки диапазон, който можете да назовете, преди да започнете, и тествайте заявка до всеки ping. Дестинация, открита по време на теста, е тази, която се забравя в записа за промени. Маршрут, който отговаря по адрес, но се проваля по име, обикновено е проблем на резолвера в костюм на маршрутизация.

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

Linux SSL клиентът има специфичен за поле отказ, който си струва да се знае: тунелът се свързва, офис LAN отговаря, а един диапазон DMZ остава тъмен. Липсващото парче е маршрут за този диапазон през тунелния шлюз, а шлюзът е различен при различните машини, затова твърдо зададеният адрес е начинът, по който се чупи следващият лаптоп. Изведете го от състоянието на клиента и оставете командата самодокументираща се:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

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

След следващото свързване и кога да спрете да правите това локално

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

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

Контролният списък е кратък: прочетете таблицата, изтрийте тунелния маршрут по подразбиране, възстановете LAN маршрута по подразбиране, добавете всеки префикс, поправете разрешаването отделно и очаквайте маршрутите да се върнат при повторно свързване.

Подобни статии