Какво променя политическата маршрутизация за VPN трафика и какво не

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

Правилата избират таблицата, после таблицата избира маршрута

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

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

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

Четете набора от правила като последователност, не като списък

Изведете правилата с приоритетите им и таблиците, към които сочат, после изведете всяка таблица, която носи маршрут по подразбиране или маршрут за тунел. Редът е важната част и именно него екранната снимка обикновено пропуска:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

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

Маркировки и сокети: два начина, по които клиентите разделят трафика

Някои клиенти маркират пакети в защитната стена и добавят правило, което съвпада с маркировката. Други използват маршрутизация на ниво сокет, задавайки маршрут на сокета преди свързване. Първото е видимо в ip rule; второто не е и няма да се появи в общо търсене.

Ако тестова програма се държи различно от приложението, което трябва да представлява, проверете дали приложението задава маркировка или се обвързва с устройство. Тази разлика не е мистерия, след като механизмът бъде назован, и обяснява защо curl от shell и раздел на браузъра могат да поемат различни пътища на една и съща машина. И двете техники са политическа маршрутизация в широк смисъл: те избират път чрез нещо различно от дестинацията. Нито една от тях не оторизира трафика и нито една не замества правилата на защитната стена или идентификационните данни, които партньорът очаква.

Проследете собствеността, преди да добавите още едно правило

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

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

Докажете обхвата с два потока, не с един

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

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

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

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