Dante SOCKS na loopback dla usługi HTTPS działającej tylko przez WireGuard

Przypisz dedykowany nasłuch SOCKS do loopback i zezwól na jeden cel TCP. Utrzymuj osobno źródło wychodzące Dante, trasę jądra, DNS i politykę utraty tunelu.

Ten poradnik daje aplikacji świadomej proxy dostęp do istniejącej trasy WireGuard bez publikowania portu proxy na serwerze VPN ani w internecie. Demon SOCKS dostarcza interfejs aplikacji, WireGuard dostarcza już zatwierdzoną trasę IP, a żaden z nich nie uwierzytelnia użytkownika za Ciebie. Każdy krok poniżej daje coś, co możesz sprawdzić, i każdy ma wycofanie: zatrzymaj instancję, usuń regułę lub usuń ustawienie proxy aplikacji. Nic tutaj nie zmienia domyślnej trasy hosta.

Przykład zakłada, że Dante 1.4.x jest zainstalowany jako dedykowana, zarządzana instancja na zaufanej stacji roboczej Linux, a konto usługi i konfiguracja logowania dostarczone przez pakiet pozostają na miejscu. Stacja robocza posiada 10.77.0.2 na swoim interfejsie WireGuard, dociera do 10.60.0.20:443 przez ten tunel, a właściwa nazwa usługi to app.corp.example.

Krok 1: przypisz nasłuch tylko do loopback

Umieść sekcje sieci, metody i reguł w aktywnej konfiguracji instancji, zastępując przykładowe adresy. Wszystkie ustawienia serwera idą przed blokami reguł:

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
}

To jest fragment, a nie zamiennik ustawień użytkownika i logowania z pakietu. Wybierz nieużywany lokalny port i potwierdź, że ta dedykowana instancja nie ma innych nasłuchów, szerszych reguł przepuszczania ani wpisów łańcucha nadrzędnego, które zmieniłyby kontrakt. Jeśli poprzednia konfiguracja pozostawiła socks pass bez ograniczenia celu, usuń ją przed czymkolwiek testować.

Wycofanie tego kroku to zatrzymanie instancji; plik konfiguracyjny może pozostać na dysku, gdy go przywracasz.

Krok 2: napisz dwie reguły, a nie jedną

Dokumentacja konfiguracji Dante przypisuje obu typom reguł różne zadania. Reguła klienta dopuszcza połączenie z nasłuchem loopback, a jej celem jest adres samego nasłuchu. Reguła SOCKS zezwala na żądane dalsze połączenie z zatwierdzonym hostem i portem. Niepasujące żądania są domyślnie blokowane, dlatego brakująca reguła wygląda identycznie jak zepsuta trasa.

Zwróć uwagę, czego ta konfiguracja świadomie nie robi: nie prosi o hasło SOCKS. To pasuje do zaufanego hosta lokalnego i nie jest uwierzytelnianiem użytkownika. Każdy inny proces na tej maszynie też może używać loopback. Zachowaj własne uwierzytelnianie zdalnej aplikacji i nie używaj ponownie tej nieuwierzytelnionej formy dla niezaufanych użytkowników lokalnych ani nasłuchu skierowanego do sieci LAN.

Krok 3: zweryfikuj trasę z właściwego źródła

external wybiera wychodzący adres źródłowy; nie instaluje trasy WireGuard. Odczyt zapytania dla przykładowego źródła i celu:

ip -4 route get 10.60.0.20 from 10.77.0.2

Uruchom to w rzeczywistej przestrzeni nazw sieci Dante, a nie w dowolnej otwartej powłoce. Trasa, wybór partnera WireGuard, uprawnienie po stronie zdalnej i droga powrotna muszą pasować do tego adresu źródłowego. Udane zapytanie jest konieczne i niewystarczające, bo nic nie mówi o tym, czy drugi koniec akceptuje żądanie.

Oprzyj się pokusie dodania trasy domyślnej, aby zapytanie się powiodło. Port proxy istnieje tylko na tej stacji roboczej; zmiana domyślnej trasy hosta, aby go utworzyć, odwraca cały projekt.

Krok 4: testuj z zamierzoną tożsamością

Po tym, jak właściciel zweryfikuje zainstalowaną konfigurację i uruchomi instancję przez swój menedżer usług, przykładowe żądanie to:

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

Z socks5h Dante wykonuje rozwiązywanie celu, ale Dante działa na tej stacji roboczej, więc ustawienie samo nie wysyła DNS do zdalnego końca tunelu. Zatwierdzony resolver używany przez Dante musi zwrócić dozwolony adres dla tej nazwy. Pusta lista bez proxy nie pozwala odziedziczonemu wyjątkowi po cichu ominąć SOCKS.

Zachowaj w teście walidację nazwy hosta i certyfikatu HTTPS, następnie sprawdź rzeczywisty nasłuch i potwierdź obie połowy kontraktu: dozwolone żądanie kończy się sukcesem, a wykluczony cel nie. Sprawdź też, że nieobsługiwane polecenia przekazywania pozostają odrzucane, ponieważ ten fragment zezwala na polecenie SOCKS CONNECT przez TCP i nic przypominającego ogólny tunel UDP lub całego urządzenia.

Krok 5: zdecyduj, co się dzieje, gdy tunel padnie

Przetestuj utratę tunelu i restart instancji, zanim nazwiesz to produkcją. Nadzorca, który uruchamia Dante po WireGuard, nie tworzy rutingu fail-closed ani nie tworzy DNS fail-closed; oba muszą być wymuszone przez właściciela sieci. Obserwuj, co robi aplikacja, gdy tunel jest wyłączony: czysty błąd to dobry wynik, ciche przejście do publicznego resolvera nie.

Koordynuj aktualizacje, jeśli powiązany adres tunelu się zmieni, ponieważ external jest do niego przypięty. Gdy układ nie jest już potrzebny, wycofaj tę instancję i ustawienie proxy aplikacji razem, a trasę WireGuard zostaw temu, kto ją posiada.

Powiązane artykuły