Как да изпратите една IPv4 дестинация извън тунел на OpenVPN

Повечето конфигурации с пълен тунел изпращат всеки пакет през VPN и директивата redirect-gateway прави точно това. Една отделна дестинация все пак може да бъде изключена. Добавянето на маршрут до хост за този адрес с контейнера net_gateway казва на клиента да го достигне през оригиналния шлюз на машината, докато всичко останало продължава да използва тунела.

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

Какво всъщност обозначава net_gateway

Записът в профила за това изключение е един ред: route 198.51.100.77 255.255.255.255 net_gateway. Първият адрес е документационен контейнер за дестинацията, маската го прави маршрут до един хост, а последният токен обозначава контейнера за шлюз. OpenVPN разрешава контейнерите за шлюз, когато инсталира маршрути. vpn_gateway означава собствения шлюз на тунела, далечната страна на VPN връзката. net_gateway означава шлюза по подразбиране, който хостът е имал преди VPN да промени нещо, което обикновено е локалният рутер във физическата мрежа.

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

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

Защо маршрутът до хост побеждава маршрута по подразбиране на тунела

Маршрутизацията се решава от най-специфичния съвпадащ префикс. redirect-gateway def1 обикновено не замества маршрута по подразбиране; той добавя две половини, маршрут за долната половина на адресното пространство и един за горната половина, така че оригиналният маршрут по подразбиране се запазва за други нужди. Тези половини са по-широки от един адрес.

Маршрут за един адрес с маска 255.255.255.255 е /32 и това е максималната специфичност, която IPv4 позволява. Когато се оценява пакет за този адрес, /32 съвпада и печели независимо кой маршрут е бил инсталиран първи. Това е механизмът зад изключението и той работи по същия начин на Linux, macOS и Windows, стига маршрутът наистина да присъства.

Windows добавя второ измерение. Когато два маршрута са еднакво специфични, печели този с по-ниска метрика, а VPN адаптерът може да носи метрика на интерфейса, която променя резултата. /32 все още е по-специфичен от половините, така че изключението обикновено се запазва, но остарял маршрут от предишна сесия може да даде объркващ резултат, ако е еднакво специфичен.

Какво не покрива изключението

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

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

Обхватът на приложенията е третият. Правилото е базирано на дестинация, така че всеки процес, който се свързва с този адрес, използва директния път, независимо дали е този, който сте имали предвид. Обратно, един сайт може да отговаря от няколко адреса, така че изключването на един /32 не изключва сайта. Ако истинското изискване е маршрутизиране по приложения, таблицата с маршрути на клиента Community е грешният инструмент.

Проверка на изключението без да се заблуждавате

Започнете с инсталирания маршрут, а не с браузър. На Linux попитайте ядрото кой маршрут и следващ хоп ще използва за конкретния адрес; на Windows прочетете таблицата с маршрути за този /32. Потвърдете, че шлюзът е физическият, а не тунелът. Ако записът липсва, профилът не е приложен или клиентът не е имал права да променя маршрути.

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

Накрая проверете контролите, които могат да надделеят над маршрута. Kill switch от страна на клиента или настройка block-outside-dns в Windows може да забрани директния трафик и това се проявява като връзка, която се проваля, въпреки че маршрутът е правилен. Не изключвайте тези контроли, за да изглежда, че изключението работи; ако политиката забранява директния път, изключението е проблем в дизайна за този, който притежава VPN услугата.

Проверете отново след повторно свързване или смяна на мрежата, защото шлюзът преди VPN и наличният път са свойства на момента, а не на профила.