Дайте на VPN потребителите достъп до една услуга, а не до подмрежата

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

Опишете изискването като услуга, не като подмрежа

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

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

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

Маршрутизирайте тясно, но налагайте другаде

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

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

Документирайте точката на налагане изрично, иначе следващата промяна ще я премести случайно.

Проверете източника, който услугата действително вижда

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

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

Запишете кое от двете избрахте, до правилото, което зависи от него.

Оторизацията на приложението не е по избор

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

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

Дръжте мрежовото правило и ролята на приложението в отделни системи и ги пенсионирайте отделно.

Докажете и разрешения, и отказания път

Свържете се като оторизиран потребител и извършете една безобидна представителна операция, после опитайте дестинация, която трябва да е недостъпна. Дизайн, който тества само първата половина, не е тестван, и тестът за отказ е този, който доказва дизайна. Тествайте нова сесия след всяка промяна на правилото и погледнете обратния път, ако заявките пристигат, а отговорите не.

Не изключвайте филтрите за препращане, за да мине приемният тест, защото това променя нещото, което се тества.

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