Dante SOCKS през VPN: пълен тунел срещу маршрутизация по източник

Искате трафикът на SOCKS прокси да излиза през VPN, докато останалата част от хоста запазва нормалния си път. Това го правят два дизайна и те се различават по това какво се чупи, когато нещо тръгне наред. Единият избутва маршрут по подразбиране в тунела и после заобикаля около него; другият оставя главната таблица непокътната и изпраща един адрес на източник към втора таблица. Вторият е по-чист и има собствени капани.

Два дизайна, два различни радиуса на поражение

Дизайнът с пълен тунел е това, което повечето VPN клиенти правят по подразбиране: заменят маршрута по подразбиране, така че всичко да следва тунела, и след това изключват това, което не бива. Лесно е да се обмисли и трудно да се поддържа тесен, защото всяка локална услуга, която добавите, наследява тунела, докато не я изключите. Режимът на отказ е широк, защото един грешен маршрут отнася със себе си собствената свързаност на хоста.

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

Тази теснина е и ограничението: дизайнът работи само ако изходящите пакети на проксито наистина носят този адрес.

Какво прави настройката external в Dante

Настройката external избира адресите, които проксито използва за изходящи връзки; тя не докосва маршрутната политика на ядрото. Именно това разделение прави втория дизайн възможен и точно тук хората прочитат документацията погрешно. Насочването на external към адрес на тунел кара проксито да извежда връзките си от този адрес, а после маршрутната таблица решава накъде отиват тези пакети.

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

Потвърдете, че конфигурираният адрес наистина принадлежи на тунела в мрежовото пространство от имена на проксито.

Изграждане на таблицата с избор по източник

За TUN адрес 10.90.0.2/24 с достижим партньор на 10.90.0.1 и номер на таблица, който нищо друго не използва, подредбата изглежда така:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

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

Тези стойности описват една топология. Партньори точка-до-точка, адресиране net30 и клиенти, които раздават различен префикс, всички се нуждаят от собствени маршрути, затова копирайте формата, а не адресите.

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

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

DNS е другото изтичане. Сокетът на резолвера не използва непременно източника на изходящите данни на проксито, така че търсенето на имена все още може да излиза през WAN. Тествайте разрешаването отделно от установяването на връзката и решете дали този резултат е приемлив.

IPv6 се нуждае от собствени правила и маршрути, защото подредбата за IPv4 не доказва нищо за него.

Изберете според отказа, който можете да понесете

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

Кое и да изберете, проверявайте от двете страни: заявка през проксито и директна заявка от хоста, като за всяка се записва наблюдаваният адрес на изход.

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