Статични адреси на тунел в pfSense: предпочитание или резервация?

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

Какво всъщност обещава адресът на отменяне

Отменянето, специфично за клиента, носи опции за отделния клиент, включително предпочитан адрес на тунела. Netgate описва този адрес като предпочитание, а не като резервация, което означава, че динамичният пул не отстъпва адреса на никого другиго.

Обикновено това е добре. Сблъсъкът е рядък и клиентът обикновено получава поисканото, което е достатъчно за удобство и не е достатъчно за оторизация. Удобството и оторизацията са различни изисквания и само едно от тях преживява сблъсък.

При топология на подмрежа полето приема адреса на клиента заедно с маската на мрежата на сървъра, така че адрес вътре в тунел 10.90.0.0/24 се записва като 10.90.0.10/24.

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

Затворете динамичния път с ограничено значение по подразбиране

Алтернативата е сървър само със статични адреси: всяка допусната крайна точка има собствена идентичност и собствен уникален адрес и нищо друго не влиза.

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

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

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

Съпоставяйте с идентичността, която сървърът наистина използва

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

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

Запазете допълнителните фактори за удостоверяване, които изисква внедряването. Затвореният модел на адреси променя кой може да се свързва и какъв адрес получава; той не замества проверката на сертификата или втория фактор.

Напишете правилата за достъп, след като картата е вярна

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

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

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

Тествайте негативните случаи

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

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

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