Два клиенти на истиот OpenVPN сервер можат да стигнат еден до друг дури и откако додадовте DROP правило за нивниот пул. Правилото стои во FORWARD веригата, сообраќајот очигледно тече, а бројачот на тоа правило останува на нула. Природниот заклучок е дека огнениот ѕид е расипан. Почесто пакетот воопшто не влегол во веригата.

Постојат два патишта по кои еден партнерски пакет може да помине низ OpenVPN сервер, и ги одредува конфигурацијата, а не огнениот ѕид. Знаењето кој пат се користи ви кажува дали правилото на домаќинот е воопшто на вистинското место.

Два патишта по кои може да помине партнерски пакет

Кога опцијата за внатрешно препраќање е исклучена, пакет од клиентот A пристигнува на тунелскиот интерфејс со дестинација внатре во доделената адреса на клиентот B. Табелата за рутирање на серверот го праќа назад низ истиот тунелски интерфејс, бидејќи рутата до адресата на B му припаѓа на серверот. Тоа е влезно-излезен тек низ домаќинот, и патот за препраќање IPv4 го оценува.

Кога опцијата за внатрешно препраќање е вклучена, серверскиот процес го совпаѓа пакетот со поврзан клиент и го запишува назад директно кај тој клиент. Пакетот се обработува внатре во демонот и никогаш повторно не влегува во тунелскиот уред, па патот за препраќање на домаќинот целосно се прескокнува. Прирачникот за OpenVPN 2.6 ја опишува оваа опција како внатрешно препраќање од клиент кон клиент, и токму затоа правилото на огнениот ѕид на домаќинот не може да го види.

Постои трета варијанта во распоредувања што го пренесуваат податочниот канал во модул на јадрото. Одлуката за препраќање и шифрирањето излегуваат од корисничкиот простор, а дали netfilter го гледа текот зависи од тоа како е изграден патот на пренесување. Никогаш не претпоставувајте дека стар сет правила се однесува на пренесен сервер исто како на оној во корисничкиот простор. Потврдете го режимот од конфигурацијата што работи, а не од верзијата на пакетот.

Кога бројачот никогаш не се поместува

Нултиот бројач значи дека пакетот не се совпаднал со тоа правило во таа точка, а причините се неколку. Првата е заобиколувањето погоре: сообраќајот никогаш не стигнал до веригата. Втората е несовпаѓање во интерфејсот, насоката, изворот или дестинацијата, што е вообичаено кога пулот е пренумериран, а правилото се уште го наведува стариот префикс.

Третата е положбата. Правило порано во веригата може да го прифати текот пред вашето DROP да биде оценето, а правило подоцна може да биде тоа што всушност одлучува за исходот. Читајте ја веригата по ред со видливи бројачи, потоа проверете кое правило го зголемува бројот кога ќе го повторите тестот.

Изведете една контролирана размена меѓу два клиенти чии вистински адреси сте ги потврдиле од самата состојба на серверот, а не од закуп што го помните. Ако релевантниот бројач се уште не се поместува, сомневајте се во патот пред да го препишете совпаѓањето. Ако се поместува, но врската се уште успева, отфрлањето подоцна се надвладува и проблемот е во редоследот. Тој одговор одлучува дали поправката е промена на правило или промена на топологија, затоа добијте го пред да уредите нешто.

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

Ако политиката мора да живее во огнениот ѕид на домаќинот, ставете го сообраќајот таму каде што огнениот ѕид може да го види. Исклучувањето на внатрешното препраќање е поддржаниот начин да се направи партнерскиот сообраќај да помине низ тунелскиот интерфејс и патот за препраќање, по цена секој партнерски пакет да помине низ стекот на домаќинот.

Потоа прецизно совпаѓајте го текот. Сообраќајот пристигнува на тунелскиот интерфејс и излегува низ тунелскиот интерфејс, во двете насоки, па правилата што ја земаат предвид само физичката интерфејс нема да се совпаднат. Правилата засновани на адреси бараат тековниот пул и мора да ја земат предвид повратната насока исто како и напредната.

Многу распоредувања подобро служат со филтрирање на ниво на клиент или група, каде идентитетот е познат и политиката го следи корисникот наместо адреса што се менува при повторно поврзување. Тоа е различен механизам од верига на домаќин, и двете не треба да се мешаат без јасна причина.

Не пренесувајте го сетот правила на стара топологија низ миграција без промени. Пуловите адреси, имињата на интерфејсите и режимите на препраќање сите влијаат дали правилото се совпаѓа, а копирано правило што порано работело е најзабунувачкиот вид доказ. Започнете од текот што сакате да го дозволите и напишете правило што му одговара.

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

Тестирајте го забранетиот случај и дозволениот случај во едно извршување. Започнете нова врска од едниот клиент до другиот и потврдете дека не успева, потоа потврдете дека врска што треба да биде дозволена се уште работи. Ако се тестира само првата, огнен ѕид што блокира се изгледа како успех.

Повторете по повторното вчитување на конфигурацијата на серверот и откако клиент ќе се поврзе повторно, бидејќи внатрешното препраќање и доделувањата на пулови се состојба во време на извршување. Проверете ги бројачите во двете насоки, бидејќи правило што се совпаѓа со една насока а не со одговорот создава делумна изолација што тешко се забележува во брз тест.

Изолацијата е набљудуваниот резултат на границата што навистина го носи текот. DROP правило некаде во домаќинот не е доказ; неуспешна врска плус поместен бројач на правилото што ја предизвикало е доказ.

Поврзани статии