Обединен или отделен VPN шлюз: изберете по домейн на отказ

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

Какво спира при едно рестартиране

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

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

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

Отбележете къде се прилага всяко правило

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

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

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

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

Изолацията е граница, не корпус

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

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

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

Възстановете това, до което наистина достигате

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

systemctl status strongswan
nft list ruleset
ip -brief address

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

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