Пълният тунел уби SSH сесията ви: заковаване на обратния маршрут

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

Какво всъщност инсталира redirect-gateway

Във формата def1 redirect-gateway добавя 0.0.0.0/1 и 128.0.0.0/1 вместо да презаписва маршрута по подразбиране. Тези две половини покриват цялото адресно пространство, като и двете остават по-дълги префикси от 0.0.0.0/0, така че всяка дестинация без по-конкретно съвпадение вече влиза в тунела. Това е механизмът, който трябва да запомните, защото всяка поправка по-долу работи чрез инсталиране на по-конкретно съвпадение.

Административният ви адрес е една от тези дестинации.

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

ip route show table main | head -n 20
ip route get 198.51.100.23

Намерете адреса си на източник и пътя преди тунела

На сървъра изброете установената SSH връзка и запишете адреса на партньора, от който е дошла. Точно този адрес трябва да покрие обратният ви маршрут и той не винаги е този, който мислите: хост за прескачане, NAT шлюз или преводач на оператора могат да подменят източника.

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

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

Заковайте хост маршрут, който превъзхожда половинките по подразбиране

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Проверете с търсене, а не с оглед на таблицата: отговорът трябва да посочва eth0 и шлюза, никога tun0.

OpenVPN вече добавя хост маршрут към собствения адрес на VPN сървъра по същата причина, така че шаблонът е познат и административният адрес е просто още едно изключение. Не прибягвайте до route-nopull за поправка, защото той изхвърля изпратените маршрути, от които тунелът се нуждае, включително отдалечената мрежа и опциите за DNS.

Направете го да преживее повторно свързване

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

Както route-up скрипт, така и pre-up куката на мрежовия мениджър работят, а надеждната проверка е повторно свързване, последвано от същото търсене.

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

Когато закован маршрут все още не е достатъчен

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

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

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