Dante SOCKS на loopback для HTTPS-сервісу лише через WireGuard

Прив'яжіть окремий SOCKS-слухач до loopback і дозвольте одне TCP-призначення. Тримайте окремо вихідне джерело Dante, маршрут ядра, DNS і політику втрати тунелю.

Цей посібник дає застосунку, обізнаному з проксі, доступ до наявного шляху WireGuard, не публікуючи проксі-порт на сервері VPN або в інтернеті. Демон SOCKS надає інтерфейс застосунку, WireGuard надає вже схвалений IP-шлях, і жоден із них не автентифікує користувача за вас. Кожен крок нижче створює щось, що можна перевірити, і кожен має відкат: зупиніть екземпляр, видаліть правило або приберіть налаштування проксі в застосунку. Ніщо тут не змінює маршрут за замовчуванням хоста.

Приклад припускає, що Dante 1.4.x встановлено як окремий керований екземпляр на довіреній робочій станції Linux, а службовий обліковий запис і конфігурацію журналювання з пакета залишено на місці. Робоча станція володіє 10.77.0.2 на своєму інтерфейсі WireGuard, досягає 10.60.0.20:443 через цей тунель, а власна назва сервісу — app.corp.example.

Крок 1: прив'яжіть слухач лише до loopback

Розмістіть розділи мережі, методу та правил в активній конфігурації екземпляра, замінивши зразкові адреси. Усі налаштування сервера йдуть перед блоками правил:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

Це фрагмент, а не заміна налаштувань користувача й журналювання з пакета. Виберіть невикористаний локальний порт і підтвердьте, що цей окремий екземпляр не має інших слухачів, ширших правил пропуску та записів вищого ланцюга, які змінили б контракт. Якщо попередня конфігурація залишила socks pass без обмеження призначення, видаліть його перед будь-яким тестуванням.

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

Крок 2: напишіть два правила, а не одне

Довідка з конфігурації Dante дає двом типам правил різні завдання. Правило клієнта допускає з'єднання зі слухачем loopback, і його призначенням є адреса самого слухача. Правило SOCKS дозволяє запитане подальше з'єднання зі схваленим хостом і портом. Невідповідні запити блокуються за замовчуванням, тому відсутнє правило виглядає так само, як зламаний маршрут.

Зверніть увагу, чого ця конфігурація навмисно не робить: вона не запитує пароль SOCKS. Це підходить для довіреного локального хоста, і це не автентифікація користувача. Будь-який інший процес на цій машині теж може використовувати loopback. Збережіть власну автентифікацію віддаленого застосунку і не використовуйте повторно цю неавтентифіковану форму для недовірених локальних користувачів або слухача, зверненого до LAN.

Крок 3: перевірте маршрут із правильного джерела

external вибирає вихідну адресу джерела; він не встановлює маршрут WireGuard. Запит лише для читання для зразкового джерела й призначення:

ip -4 route get 10.60.0.20 from 10.77.0.2

Виконуйте це в реальному мережевому просторі імен Dante, а не в будь-якій випадково відкритій оболонці. Маршрут, вибір партнера WireGuard, дозвіл на віддаленій стороні та зворотний шлях мають відповідати цій адресі джерела. Успішний запит необхідний і недостатній, бо він нічого не каже про те, чи приймає далекий кінець запит.

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

Крок 4: тестуйте з передбаченою ідентичністю

Після того як власник перевірить встановлену конфігурацію й запустить екземпляр через свій менеджер служб, зразковий запит такий:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

З socks5h Dante виконує розв'язання призначення, але Dante працює на цій робочій станції, тому налаштування саме по собі не надсилає DNS на далекий кінець тунелю. Схвалений резолвер, який використовує Dante, має повернути дозволену адресу для цього імені. Порожній список без проксі не дає успадкованому винятку тихо обійти SOCKS.

Збережіть у тесті перевірку імені хоста й сертифіката HTTPS, потім огляньте реальний слухач і підтвердьте обидві половини контракту: дозволений запит проходить, а виключене призначення — ні. Також переконайтеся, що непідтримувані команди пересилання залишаються забороненими, бо цей фрагмент дозволяє команду SOCKS CONNECT через TCP і нічого схожого на загальний UDP- або тунель усього пристрою.

Крок 5: вирішіть, що станеться, коли тунель упаде

Перевірте втрату тунелю й перезапуск екземпляра, перш ніж називати це виробництвом. Супервізор, який запускає Dante після WireGuard, не створює fail-closed маршрутизацію і не створює fail-closed DNS; обидва мають забезпечуватися через власника мережі. Спостерігайте, що робить застосунок, коли тунель лежить: чиста помилка — добрий результат, тихий перехід на публічний резолвер — ні.

Узгоджуйте оновлення, якщо прив'язана адреса тунелю змінюється, бо external прикріплений до неї. Коли схема більше не потрібна, виведіть цей екземпляр і налаштування проксі застосунку разом і залиште шлях WireGuard тому, хто ним володіє.

Схожі статті