Jak czytać błąd SO_ORIGINAL_DST w Squidzie

NF getsockopt(SO_ORIGINAL_DST) wskazuje na wyszukiwanie pierwotnego celu. W konfiguracji przechwytywania Squid musi odtworzyć, dokąd pierwotnie zmierzało przekierowane połączenie.

Jawnie skonfigurowana przeglądarka celowo wysyła żądania do proxy. To połączenie nie zyskuje historii przechwytywania NAT tylko dlatego, że obok portu nasłuchu Squida widnieje intercept.

Ta niezgodność może więc zawieść, zanim certyfikat celu w ogóle zacznie mieć znaczenie.

Zacznij od tego, jak dotarło połączenie

• Jeśli aplikacja ma skonfigurowany adres proxy, ustal zwykły nasłuch proxy przekazującego, którego powinna używać.
• Jeśli brama przekierowuje ruch, który w innym razie byłby bezpośredni, sprawdź, czy dociera on do zamierzonego nasłuchu przechwytywania i czy obsługiwany projekt NAT zachowuje wymagane informacje o celu.
• Jeśli istnieją oba tryby, sprawdź, z jakim adresem i portem faktycznie połączył się zawodzący klient.

Dokumentacja Squida dotycząca http_port jasno rozróżnia: pominięcie flagi trybu wybiera tryb proxy przekazującego; intercept oczekuje przechwytywania NAT na poziomie IP.

Następnie zajmij się bezpieczeństwem transportu osobno. Proxy HTTP może przenosić HTTPS przez CONNECT. Połączenie TLS do proxy wymaga zgodnego nasłuchu i konfiguracji klienta. Odszyfrowywanie ruchu do celu to kolejna opcjonalna możliwość.

Nie kopiuj starego “rozwiązania HTTPS”, które włącza generowanie certyfikatów tylko dlatego, że adres celu zaczyna się od HTTPS. Najpierw napraw zgodność między klientem a nasłuchem. Jeśli potem pozostanie prawdziwy błąd TLS, będzie to bardziej użyteczny błąd do zbadania.