Как да заключим изхода на Linux, така че да не изтича нищо при падане на VPN

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

Локалният изход е различна кука от препращането

Пакет, който напуска приложение на машината, преминава през куката за изход; пакет, който машината маршрутизира за друг хост, преминава през препращане. Политика, която споменава само forward, ограничава втория случай и оставя първия напълно отворен, затова толкова много заключвания на изхода изглеждат правилни и не правят нищо. Съпоставянето на интерфейс принадлежи в същото правило: oifname "tun0" accept пропуска трафик, който вече е бил маршрутизиран през тунела. Маршрутизацията и филтрирането също остават отделни решения, така че маршрут към доставчика може да съществува, докато филтърът отказва пакета. Точно на това разделение разчитате.

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

Напишете списъка с изключения от крайната точка навън

Започнете от крайната точка на тунела: един адрес на местоназначение или малък одобрен набор, транспортния протокол и порта на местоназначение, например udp dport 1194 ip daddr 203.0.113.7 accept. Ако клиентът резолвва име на хост, първоначалният DNS обмен се нуждае от собствено правило, ограничено до резолвъра и до порт 53, а не общо разрешение за адреса на този резолвър. Всяко изключение трябва да назовава причината, поради която съществува. Разрешение за целия UDP трафик към VPN порта покрива много повече от единствената удостоверена услуга, която сте имали предвид.

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

Локалната администрация се нуждае от същото отношение. Управляваща подмрежа не е надеждна, защото адресите ѝ са частни, а правило, което ѝ вярва, кани втори път около заключването.

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

Правила, които приемат всичко, излизащо от tun0, предполагат, че пакет на този интерфейс е дошъл от тунела. Имената на интерфейсите се пресъздават, а името не е криптографска идентичност. Освен това партньорът може да е изчезнал, докато интерфейсът остава вдигнат, което прави правилото много убедително бездействие.

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

Какво оцелява при срив на демона

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

Изтриването на маршрута по подразбиране също не е заместител. Маршрутът е състояние, което демонът притежава и пренаписва, и премахването му може да отнеме пътя, нужен за повторно свързване. IPv6 се нуждае от собствен план, защото откриването на съседи и обявите на рутера са услуги на връзката, които трябва да продължат да работят, докато обикновеният трафик е блокиран. DHCP попада в същата категория. Записвайте тези неща като изключения с предназначение, вместо да ги откривате по-късно като прекъсвания.

Път за възстановяване преди внедряване

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

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