Dante SOCKS na loopbacku pro HTTPS službu pouze přes WireGuard

Navázejte vyhrazený SOCKS posluchač na loopback a povolte jeden cíl TCP. Odchozí zdroj Danteho, jádrovou trasu, DNS a politiku výpadku tunelu držte odděleně.

Tento návod dává aplikaci, která rozumí proxy, přístup k existující cestě WireGuard, aniž by publikoval port proxy na serveru VPN nebo na internetu. Démon SOCKS poskytuje rozhraní aplikace, WireGuard poskytuje již schválenou IP cestu a ani jeden z nich za vás uživatele neověřuje. Každý krok níže vytváří něco, co můžete zkontrolovat, a každý má i návrat: zastavte instanci, odeberte pravidlo nebo zrušte nastavení proxy v aplikaci. Nic zde nemění výchozí trasu hostitele.

Příklad předpokládá, že Dante 1.4.x je nainstalován jako vyhrazená, spravovaná instance na důvěryhodné linuxové pracovní stanici, se servisním účtem a konfigurací protokolování z balíčku ponechanými na místě. Pracovní stanice vlastní 10.77.0.2 na svém rozhraní WireGuard, dosahuje 10.60.0.20:443 přes tento tunel a vlastní název služby je app.corp.example.

Krok 1: navázejte posluchač pouze na loopback

Vložte sekce sítě, metody a pravidel do aktivní konfigurace instance a nahraďte ukázkové adresy. Všechna nastavení serveru jdou před bloky pravidel:

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
}

Toto je fragment, nikoli náhrada uživatelských a logovacích nastavení balíčku. Vyberte nepoužívaný lokální port a potvrďte, že tato vyhrazená instance nemá jiné posluchače, žádná širší pravidla průchodu ani záznamy nadřazeného řetězení, které by změnily kontrakt. Pokud předchozí konfigurace ponechala socks pass bez omezení cíle, odstraňte jej dříve, než cokoli otestujete.

Návratem pro tento krok je zastavení instance; konfigurační soubor může zůstat na disku, dokud jej vracíte.

Krok 2: napište dvě pravidla, ne jedno

Danteho referenční příručka konfigurace dává oběma typům pravidel různé úkoly. Klientské pravidlo připouští spojení k posluchači na loopbacku a jeho cílem je adresa samotného posluchače. Pravidlo SOCKS povoluje požadované navazující spojení ke schválenému hostiteli a portu. Neodpovídající požadavky se ve výchozím stavu blokují, a proto chybějící pravidlo vypadá stejně jako rozbitá trasa.

Všimněte si, co tato konfigurace záměrně nedělá: nevyžaduje žádné heslo SOCKS. To se hodí pro důvěryhodný lokální hostitel a není to ověřování uživatele. Jakýkoli jiný proces na tom stroji může loopback používat také. Ponechte vlastní ověřování vzdálené aplikace a tento neověřený tvar znovu nepoužívejte pro nedůvěryhodné lokální uživatele ani pro posluchač obrácený do LAN.

Krok 3: ověřte trasu ze správného zdroje

external vybírá odchozí zdrojovou adresu; neinstaluje trasu WireGuard. Vyhledání pouze pro čtení pro ukázkový zdroj a cíl:

ip -4 route get 10.60.0.20 from 10.77.0.2

Spusťte to ve skutečném síťovém jmenném prostoru Danteho, ne v jakémkoli shellu, který máte zrovna otevřený. Trasa, výběr partnera WireGuard, oprávnění na vzdálené straně i zpětná cesta musí odpovídat této zdrojové adrese. Úspěšné vyhledání je nutné, ale ne dostačující, protože nic neříká o tom, zda vzdálený konec požadavek přijme.

Odolejte pokušení přidat výchozí trasu, aby vyhledání uspělo. Port proxy existuje jen na této pracovní stanici; změna výchozí trasy hostitele, abyste jej vytvořili, obrací celý návrh naruby.

Krok 4: testujte se zamýšlenou identitou

Poté co vlastník ověří nainstalovanou konfiguraci a spustí instanci přes svého správce služeb, je ilustrativní požadavek tento:

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

S socks5h provádí Dante rozlišení cíle, ale Dante běží na této pracovní stanici, takže nastavení samo neposílá DNS na vzdálený konec tunelu. Schválený resolver, který Dante používá, musí pro tento název vrátit povolenou adresu. Prázdný seznam bez proxy brání zděděné výjimce tiše obejít SOCKS.

V testu zachovejte ověřování názvu hostitele a certifikátu HTTPS, poté zkontrolujte skutečný posluchač a potvrďte obě poloviny kontraktu: povolený požadavek uspěje a vyloučený cíl selže. Ověřte také, že nepodporované příkazy předávání zůstávají zakázané, protože tento fragment povoluje příkaz SOCKS CONNECT přes TCP a nic podobného obecnému UDP nebo tunelu celého zařízení.

Krok 5: rozhodněte, co se stane, když tunel spadne

Otestujte ztrátu tunelu a restart instance, než to nazvete produkcí. Supervisor, který spouští Danteho po WireGuardu, nevytváří fail-closed směrování a nevytváří ani fail-closed DNS; obojí musí být vynuceno přes vlastníka sítě. Sledujte, co aplikace dělá, když je tunel mimo provoz: čistá chyba je dobrý výsledek, tichý návrat k veřejnému resolveru ne.

Koordinujte aktualizace, pokud se svázaná adresa tunelu změní, protože external je na ni připevněn. Když uspořádání už není potřeba, vyřaďte tuto instanci a nastavení proxy v aplikaci společně a cestu WireGuard ponechte tomu, kdo ji vlastní.

Související články