Защо правило за блокиране на OpenVPN клиент никога не попада във FORWARD

Два клиента на един и същ OpenVPN сървър могат да се достигат, дори след като сте добавили правило DROP за техния пул. Правилото стои във веригата FORWARD, трафикът очевидно тече, а броячът на това правило остава на нула. Естественият извод е, че защитната стена е счупена. По-често пакетът изобщо не е влизал във веригата.

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

Два пътя, по които може да мине пакет от партньор

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

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

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

Когато броячът никога не се движи

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

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

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

Избор на граница, която може да филтрира

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

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

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

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

Тестване на изолация вместо доверие на правило

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

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

Изолацията е наблюдаваният резултат на границата, която действително носи потока. Правило DROP някъде в хоста не е доказателство; неуспешна връзка плюс преместен брояч на правилото, което я е причинило, е.