Dante SOCKS через VPN: повний тунель чи маршрутизація за джерелом

Два способи пропустити через тунель лише SOCKS-проксі: замінити маршрут за замовчуванням або прив'язати одну адресу джерела до власної таблиці. Вони відмовляють по-різному.

Ви хочете, щоб трафік 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 нічого про нього не доводить.

Виберіть за відмовою, яку можете витримати

Виберіть повний тунель, коли хост треба захищати в цілому і ви можете підтримувати список винятків. Виберіть маршрутизацію за джерелом, коли хост має зберегти власний шлях і перенаправити треба лише одну службу. Обидва варіанти законні; помилка — вибрати один, а потім перевіряти його так, ніби це інший.

Хоч би що ви вибрали, перевіряйте з обох боків: запит через проксі та прямий запит з хоста, із записаною спостереженою адресою виходу для кожного.

Якщо тунель упаде, заздалегідь вирішіть, чи проксі має відмовити, чи відступити, і дозвольте таблиці маршрутизації виразити це рішення.

Схожі статті