Маршрутизация по източник за два пула VPN: какво пропуска вашето правило

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

Търсенето се случва, преди източникът да бъде пренаписан

За пакет, препратен от VPN клиент, ядрото изпълнява фиксирана последователност. Той пристига на интерфейса на тунела, преминава през prerouting, където живеят conntrack и DNAT, след това се взема решение за маршрутизиране, след това препращане, след това postrouting, където SNAT се прилага последен. Правило от вида from се проверява по време на това решение за маршрутизиране, което означава, че то вижда оригиналния адрес на клиента, а не транслирания.

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

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

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

Тест от шлюза не е тест на пула

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

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

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

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

Приоритет, а не позиция във файла

Правилата се оценяват във възходящ ред на приоритета и числото е това, което има значение, а не редът, в който сте ги написали. Таблицата local е с приоритет 0, таблицата main — с 32766, а правилото по подразбиране — с 32767, затова правило, добавено с приоритет по подразбиране, попада близо до края на списъка и губи от почти всичко.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

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

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

Обратният път все още трябва да съществува

Политиката по източник избира изход. Тя не създава обратен път. Ако вторият пул излиза през партньорски тунел, партньорът трябва да знае как да достигне 172.31.8.0/24 — или чрез маршрут обратно към шлюза, или като получава транслирани адреси, които вече познава.

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

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

Не хващайте собствения тунел на шлюза в политиката

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

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

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