Dante SOCKS loopbacken egy csak WireGuardon át működő HTTPS-szolgáltatáshoz

Kössön egy dedikált SOCKS-figyelőt loopbackre, és engedjen egy TCP-célpontot. Tartsa külön a Dante kimenő forrását, a kernel útvonalát, a DNS-t és a tunnelvesztés szabályát.

Ez az útmutató egy proxy-tudatos alkalmazásnak ad hozzáférést egy meglévő WireGuard-útvonalhoz anélkül, hogy proxy-portot tenne közzé a VPN-szerveren vagy az interneten. A SOCKS-démon adja az alkalmazás interfészét, a WireGuard adja a már jóváhagyott IP-útvonalat, és egyik sem hitelesíti a felhasználót Ön helyett. Az alábbi minden lépés valami ellenőrizhetőt hoz létre, és mindegyiknek van visszaútja: állítsa le a példányt, távolítsa el a szabályt, vagy vegye ki az alkalmazás proxybeállítását. Semmi itt nem változtatja meg a gazdagép alapértelmezett útvonalát.

A példa feltételezi, hogy a Dante 1.4.x dedikált, felügyelt példányként telepítve van egy megbízható Linux munkaállomáson, a csomag által biztosított szolgáltatásfiókkal és naplózási konfigurációval a helyén hagyva. A munkaállomás a 10.77.0.2 címet birtokolja a WireGuard-interfészén, eléri a 10.60.0.20:443 címet azon a tunnelon át, és a szolgáltatás saját neve app.corp.example.

1. lépés: a figyelőt csak loopbackre kösse

Helyezze a hálózati, módszer- és szabályszakaszokat a példány aktív konfigurációjába, a példacímeket lecserélve. Minden szerverbeállítás a szabályblokkok elé kerül:

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
}

Ez egy töredék, nem a csomag felhasználói és naplózási beállításainak helyettesítője. Válasszon egy nem használt helyi portot, és igazolja, hogy ennek a dedikált példánynak nincsenek más figyelői, szélesebb átengedési szabályai és a szerződést megváltoztató felsőbb láncolási bejegyzései. Ha egy korábbi konfiguráció socks pass célkorlátozás nélkül hagyott, távolítsa el, mielőtt bármit tesztel.

Ennek a lépésnek a visszaútja a példány leállítása; a konfigurációs fájl a lemezen maradhat, amíg visszaállítja.

2. lépés: két szabályt írjon, ne egyet

A Dante konfigurációs referenciája különböző feladatot ad a két szabálytípusnak. Az ügyfélszabály engedélyezi a kapcsolatot a loopback-figyelőhöz, és célja maga a figyelő címe. A SOCKS-szabály engedélyezi a kért továbbkapcsolatot a jóváhagyott gazdagéphez és porthoz. A nem illeszkedő kérések alapértelmezés szerint blokkolva vannak, ezért a hiányzó szabály pontosan úgy néz ki, mint egy törött útvonal.

Figyelje meg, mit nem tesz meg ez a konfiguráció szándékosan: nem kér SOCKS-jelszót. Ez megbízható helyi gazdagéphez illik, és nem felhasználói hitelesítés. Bármely más folyamat azon a gépen is használhatja a loopbacket. Tartsa meg a távoli alkalmazás saját hitelesítését, és ne használja újra ezt a hitelesítés nélküli formát nem megbízható helyi felhasználókhoz vagy LAN felé néző figyelőhöz.

3. lépés: ellenőrizze az útvonalat a megfelelő forrásból

external kimenő forráscímet választ; nem telepít WireGuard-útvonalat. Csak olvasható lekérdezés a példa forrásához és céljához:

ip -4 route get 10.60.0.20 from 10.77.0.2

Futtassa ezt a Dante tényleges hálózati névterében, ne bármelyik véletlenül nyitva lévő shellben. Az útvonalnak, a WireGuard-partner kiválasztásának, a távoli oldali engedélynek és a visszaútnak mind illeszkednie kell ehhez a forráscímhez. A sikeres lekérdezés szükséges és nem elégséges, mert semmit nem mond arról, hogy a távoli vég elfogadja-e a kérést.

Álljon ellen a kísértésnek, hogy alapértelmezett útvonalat adjon hozzá, csak hogy a lekérdezés sikerüljön. A proxy-port csak ezen a munkaállomáson létezik; a gazdagép alapértelmezett útvonalának módosítása a létrehozásához az egész tervezést a feje tetejére állítja.

4. lépés: a szándékolt identitással teszteljen

Miután a tulajdonos ellenőrizte a telepített konfigurációt, és a szolgáltatáskezelőjén keresztül elindította a példányt, egy szemléltető kérés ez:

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

A socks5h beállítással a Dante végzi a cél feloldását, de a Dante ezen a munkaállomáson fut, ezért a beállítás önmagában nem küld DNS-t a tunnel távoli végére. A Dante által használt jóváhagyott feloldónak vissza kell adnia az engedélyezett címet ehhez a névhez. Az üres no-proxy lista megakadályozza, hogy egy örökölt kivétel csendben megkerülje a SOCKS-t.

Őrizze meg a tesztben a HTTPS-gazdagépnév és a tanúsítvány ellenőrzését, majd vizsgálja meg a tényleges figyelőt, és erősítse meg a szerződés mindkét felét: az engedélyezett kérés sikerül, a kizárt cél pedig meghiúsul. Azt is ellenőrizze, hogy a nem támogatott továbbítási parancsok továbbra is elutasítottak maradnak, mert ez a töredék a SOCKS CONNECT parancsot engedi TCP fölött, és semmi általános UDP- vagy teljes eszközös tunnelhez hasonlót.

5. lépés: döntse el, mi történik, ha a tunnel elesik

Tesztelje a tunnel elvesztését és a példány újraindítását, mielőtt termelésnek nevezné. Az a felügyelő, amely a WireGuard után indítja a Dante-t, nem hoz létre fail-closed útválasztást, és fail-closed DNS-t sem; mindkettőt a hálózat tulajdonosán keresztül kell kikényszeríteni. Figyelje, mit tesz az alkalmazás, amikor a tunnel le van állva: a tiszta hiba jó eredmény, a csendes visszaesés egy nyilvános feloldóra nem az.

Hangolja össze a frissítéseket, ha a kötött tunnelcím megváltozik, mert external ehhez van rögzítve. Amikor az elrendezésre már nincs szükség, vonja ki ezt a példányt és az alkalmazás proxybeállítását együtt, és hagyja a WireGuard-útvonalat annak, aki birtokolja.

Kapcsolódó cikkek