Şeffaf proxy DNAT: dönüş yolu neden önemlidir
DNAT bir isteği ayrı bir proxy'ye ulaştırabilirken yanıtın ağ geçidini atlayıp bağlantıyı neden kopardığını anlayın.
Yönlendirilmiş bir SYN, istemci hâlâ zaman aşımına uğrarken Squid'e ulaşabilir. DNAT kurulumunda dönüş paketi de çeviri durumunu tutan ağ geçidine ulaşmalıdır.
Bu varsayımsal LAN'ı düşünün:
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İstemci başlangıçta bir web sitesi adresine bağlandı. DNAT sonrasında proxy istemcinin kaynağını görür ve doğrudan yanıtlamak için yerel alt ağ yolunu kullanabilir. Bu yanıt ağ geçidinin ters çevirisini atlar ve istemciye beklenen web sitesi adresi yerine proxy adresinden ulaşabilir. Ağ geçidi hiç almadığı paketleri onaramaz.
| Yaklaşım | Sonuç |
|---|---|
| Proxy'nin yanıtlarını çeviri yapan ağ geçidinden geçirmek | Proxy'ye gelen bağlantı istemcinin kaynak adresini koruyabilir |
| Uygun kaynak çevirisini de uygulamak | Proxy ağ geçidine kendi eşi olarak yanıt verir, ancak artık asıl istemci yerine o çevrilmiş kaynağı görür |
Daha güzel günlükler için dönüş yolunu doğrulamadan SNAT'i kaldırmayın. Geniş uygulama kaynak ACL'lerini ve atıfı da değiştirir; bu sonucu tasarımın parçası olarak kabul edin.
Güvenilen bir HTTP atlaması, istemci üst verisini iletme başlığında taşıyabilir, ancak NAT o başlığı oluşturmaz veya onu bir TCP eşi kimliğine dönüştürmez. Kaynağı Squid'e giden bağlantıda korumak, onu Squid'in ayrı web sitesi bağlantısında da korumaz.
Son olarak, müdahale tasarımı yine de Squid'in gerektirdiği hedef bilgilerini sağlamalıdır. Simetrik dönüş yönlendirmesi bu zaman aşımı mekanizmasını çözer, şeffaf proxy yapılandırmasının tamamını değil.