Две клиентски групи, един сървър: къде да се наложи политиката

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

Подмрежата е етикет, не правило

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

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

Изберете пътя, който носи трафика между партньорите

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

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

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

Напишете матрицата, преди да пишете правила

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

Дръжте трите класа дестинации отделно, докато я пишете. Услуга на хоста на VPN е локален вход, друг клиент е транзит между партньори, а машина зад шлюза е различен път за препращане. Едно щедро правило може случайно да разреши и трите и така груповата политика се превръща в плоска мрежа с допълнителни стъпки. Запишете класа до всеки ред, за да оцелее намерението след следващата редакция.

Поставете правилата там, където оцеляват

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

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

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

Докажете го от двете страни

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

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