Два уреда изгледаат поиздржливи од еден додека не забележите дека делат иста струјна лента, исти хипервизор и иста нагорна врска. Броењето кутии одговара на прашање што никој не го поставил; корисното прашање е што откажува во исто време. Прво запишете го договорот за дефект, потоа оставете го да ја избере топологијата. 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-от завршува кога договорот за дефект е запишан, патот за препраќање има една именувана точка за спроведување по правило, задржувањето е опишано со текови, а не со број на уреди, и враќањето работи од надвор од расипаната компонента. Изберете поедноставно уредување што ги исполнува тие барања.

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