Иста IP адреса на серверот, две патеки: означување на надворешниот тек на OpenVPN

Вообичаената заштита од јамка е рута до домаќин: испратете сообраќај до јавната адреса на VPN серверот преку uplink, за да не влезе шифрираната сесија во сопствениот тунел. Тоа функционира точно до моментот кога сакате преку тунелот да стигнете и до веб-услуга на истиот сервер, бидејќи изземеното е врзано за одредиштето, а одредиштето е исто. Излезот е да престанете да класифицирате по одредиште и да почнете да класифицирате по тоа кој сокет го испратил пакетот.

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

Едниот тек е самиот шифриран транспорт OpenVPN, кој мора да излезе преку uplink, инаку тунелот би носел сопствена надворешна врска. Другиот е обично HTTPS барање до истата јавна адреса, што го сакате внатре во тунелот за да стигне до услугата од тунелски извор. Исто одредиште, во многу случаи ист број на порта, различен потребен пат.

За овој преглед претпоставете клиент на 10.90.0.10 преку tun1, јавна адреса на серверот 198.51.100.25 и недопрена главна табела чија стандардна рута покажува кон вообичаениот uplink. Страната на серверот исто така мора да ја прифати веб-услугата на внатрешниот пат и да враќа сообраќај до тунелскиот извор; испраќањето пакет до јавна адреса не го заобиколува слушачот или firewall политиката на серверот.

Пред да смените нешто, запишете ги тековните правила на домаќинот и изберете вредности што никој друг не ги користи: ознака, број на табела и три приоритети на правила. Задржете пат назад во машината што не оди преку оваа врска, бидејќи грешка овде ви го одзема сопствениот далечински пристап, а не само крши јазиче во прелистувачот.

Означете го сокетот што ја носи обвивката

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

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

Исправката му припаѓа на сопственикот на firewall-от: зачувајте ја ознаката на излезната врска, вратете ја на соодветните влезни пакети и овозможете обработка на ознаки валидирана од изворот за релевантниот пат. Тоа што 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, а обична услуга на истата адреса не мора да го наследи.