Какво да записваме за VPN между сайтове: селектори и обхват

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

Конфигурирано не означава съгласувано

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

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

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

Тунелите на базата на маршрути избират различно

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

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

Транслацията принадлежи в същата таблица

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

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

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

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

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

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

Превърнете записа в план за тестване

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

swanctl --list-sas

Скелет от пет реда обикновено е достатъчен, за да остане записът честен. Версията по-долу се побира в билет за промяна без отрязване:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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