Маршрутизиран или мостов VPN: изберете според това какво трябва да достигне клиентът

В един и същи ден пристигат две заявки: един потребител има нужда от вътрешно уеб приложение, а един инженер има нужда стендов прибор да се държи така, сякаш стои в същия Ethernet сегмент. И на двете се отговаря с „сложете ги на VPN“, и точно там започва белята. Маршрутизираният тунел и мостовият тунел установяват различни отношения и само един от тях отговаря на всяка заявка. Изборът на топология е решение за достъп, а не криптографска настройка.

Две заявки, които изглеждат еднакви на гишето

Изискването на служителя е услуга, достъпна по IP от устройство, което не контролирате. Изискването на инженера е на ниво връзка: приборът очаква да вижда Ethernet кадри и откриване чрез broadcast, а вероятно и DHCP от сегмента, в който смята, че се намира.

Това са различни въпроси и отговорът и на двата с мост разширява достъпа на служителя до цялата офис LAN без причина.

Запишете изискването като изречение преди избора: кои дестинации, кои протоколи и кои партньори трябва да изглеждат локални. Ако отговорът е хост и порт, маршрутизирането го покрива. Ако отговорът е отношение на ниво кадър с устройства, които говорят само чрез broadcast, мостът може да е единствената опция. Всичко по средата заслужава тестов сегмент, а не продукционната LAN.

Маршрутът е по-тесен от членство в LAN

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

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

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

Мостът променя въпроса за допускане

Мостът свързва физически интерфейс и TAP устройство в софтуерен комутатор, така че отдалечените устройства се присъединяват към същия broadcast домейн. Това е реална възможност и реален риск: отдалеченото устройство вече не е маршрутизиран гост, а участник.

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

За прибора отделен тестов сегмент обикновено е по-подходящ от офис LAN. Дръжте достъпа за управление извън експеримента и определете как временният участник се премахва, когато работата приключи.

Филтрирането съществува и в двете топологии

Мостът не е поначало нефилтрируем, а маршрутът не е поначало безопасен. Филтрирането на мостове в Linux има свои куки и свой синтаксис на правила и правило, написано за маршрутизирано IP препращане, не се прилага автоматично за мостови кадри.

Проверете какво платформата действително поддържа, преди да обещаете граница:

bridge link show
nft list ruleset

TUN и TAP описват трафика на интерфейса, а не шифъра. Смяната на интерфейси не поправя нищо от това: автентикацията на партньорите, откраднатият ключ и остарялата криптографска политика всички оцеляват при промяната. Двете страни все още се нуждаят от настройки, които съвпадат и все още се поддържат.

Докажете границата с три опита

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

Изпълнете разрешения и забранения път от един и същ клиент и запишете и двата:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

За мост добавете проверките на ниво връзка: дали разрешеният трафик за откриване преминава, дали адресирането идва от предвидения орган и дали временният участник е изчезнал след премахването. Когато обикновеният маршрутизиран IP вече удовлетворява изискването, присъединяването към офис Ethernet сегмента се нуждае от отделно обосноваване и то трябва да бъде записано преди промяната.