Същият IP на сървъра, два пътя: маркиране на външния поток на OpenVPN

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

Започнете с двата потока, които искате да разделите

Единият поток е самият шифрован транспорт OpenVPN, който трябва да излезе през uplink, иначе тунелът би носил собствената си външна връзка. Другият е обикновена HTTPS заявка към същия публичен адрес, която искате вътре в тунела, за да стигне до услугата от източник на тунела. Същата дестинация, в много случаи същият номер на порт, различен необходим път.

За това разглеждане приемете клиент на 10.90.0.10 през tun1, публичен адрес на сървъра 198.51.100.25 и недокосната главна таблица, чийто маршрут по подразбиране сочи към обичайния uplink. Страната на сървъра също трябва да приема уеб услугата по вътрешния път и да връща трафика към източника на тунела; изпращането на пакет към публичен адрес не отменя слушателя или политиката на защитната стена на сървъра.

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

Маркирайте сокета, който носи плика

Конфигурацията на клиента получава маркер за своите шифровани изходящи пакети и спира сама да инсталира маршрути, така че политиката за заместване е единственото, което определя пътищата:

mark 42
route-noexec
disable-dco

Десетичното 42 е шестнадесетичното 0x2a и именно шестнадесетичната форма ще съпоставят правилата за маршрутизация. Справката за link-options описва mark като нещо, което се прилага към шифровани изходящи пакети в Linux, тоест точно сокета, чийто път трябва да управлявате. Изключването на разтоварването на канала за данни задържа този пример на пътя на потребителското пространство, където поведението на маркера е описаното.

route-noexec потиска автоматичното добавяне и премахване на маршрути от OpenVPN. Не инсталира нищо на тяхно място, затова от този момент собственикът на маршрутите трябва да поддържа всеки маршрут, от който тунелът се нуждае. Ако частна дестинация изчезне след промяната, това е липсващата политика за заместване, а не дефект в маркера.

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

Изпратете всичко останало към таблицата на тунела

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

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

Дръжте тази защита на място между прекъсванията и я инсталирайте заедно с останалата политика, а не на ръка. Правило, което изчезва с интерфейса, не е политика, а съвпадение. Изтриването на политиката, когато тунелът падне, променя режима на отказ от „блокирано“ на „изтекло“, а остарял маршрут на тунела, който по-късно изтича, е много по-лесен за обяснение проблем от трафик, излязъл през грешния интерфейс.

Нека обратният път вижда същия маркер

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

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

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

Докажете го с две търсения на маршрут

Сравнете какво решава ядрото за двата контекста и четете полетата dev и src, а не кода за изход:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Първото търсене трябва да се реши към tun1 с източника на тунела, а второто към uplink. Това са синтетични търсения, затова те доказват политиката, а не работещия процес: потвърдете отделно действителния транспортен път на работещия клиент и след това направете истинска HTTPS заявка с включена проверка на сертификата.

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