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 на този, който го притежава.

Подобни статии