DNAT przezroczystego proxy: dlaczego trasa powrotna ma znaczenie

Zrozum, dlaczego DNAT może dostarczyć żądanie do osobnego proxy, podczas gdy odpowiedź omija bramę i zrywa połączenie.

Przekierowany SYN może dotrzeć do Squida, podczas gdy klient wciąż kończy się przekroczeniem czasu. W konfiguracji DNAT pakiet powrotny również musi dotrzeć do bramy, która posiada stan tłumaczenia.

Rozważ tę hipotetyczną sieć LAN:

client 192.168.40.25 → gateway 192.168.40.1
                         DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directly

Klient początkowo połączył się z adresem witryny. Po DNAT proxy widzi źródło klienta i może użyć trasy lokalnej podsieci, aby odpowiedzieć bezpośrednio. Ta odpowiedź omija odwrotne tłumaczenie bramy i może dotrzeć do klienta z adresu proxy zamiast z oczekiwanego adresu witryny. Brama nie może naprawić pakietów, których nigdy nie otrzymuje.

PodejścieSkutek
Przepuszczać odpowiedzi proxy przez tłumaczącą bramęPołączenie przychodzące do proxy może zachować adres źródłowy klienta
Zastosować także odpowiednie tłumaczenie źródłaProxy odpowiada bramie jako swojemu partnerowi, ale teraz widzi to przetłumaczone źródło, a nie pierwotnego klienta

Nie usuwaj SNAT dla ładniejszych logów bez sprawdzenia trasy powrotnej. Szerokie stosowanie zmienia też ACL źródła i przypisanie; zaakceptuj ten skutek jako część projektu.

Zaufany przeskok HTTP może przenieść metadane klienta w nagłówku przekazywania, ale NAT nie tworzy tego nagłówka ani nie zamienia go w tożsamość peera TCP. Zachowanie źródła na połączeniu do Squida nie zachowuje go też na osobnym połączeniu Squida z witryną.

Na koniec projekt przechwytywania nadal musi zapewnić informacje o miejscu docelowym wymagane przez Squida. Symetryczne trasowanie powrotne rozwiązuje ten mechanizm przekroczenia czasu, a nie całą konfigurację przezroczystego proxy.

Powiązane artykuły