투명 프록시 DNAT: 반환 경로가 중요한 이유
DNAT가 요청을 별도 프록시로 전달해도 응답이 게이트웨이를 우회해 연결이 끊기는 이유를 이해합니다.
리디렉션된 SYN이 Squid에 도착해도 클라이언트는 여전히 시간 초과를 겪습니다. DNAT 구성에서는 반환 패킷도 변환 상태를 가진 게이트웨이에 도달해야 합니다.
이 가상의 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클라이언트는 처음에 웹사이트 주소에 연결했습니다. DNAT 후 프록시는 클라이언트의 출발지를 보고 로컬 서브넷 경로로 직접 응답할 수 있습니다. 그 응답은 게이트웨이의 역변환을 거치지 않아 기대한 웹사이트 주소가 아니라 프록시 주소에서 클라이언트에 도달할 수 있습니다. 게이트웨이는 받지 못한 패킷을 고칠 수 없습니다.
| 접근 | 결과 |
|---|---|
| 프록시의 응답을 변환하는 게이트웨이를 거쳐 보내기 | 프록시로 들어오는 연결이 클라이언트의 출발지 주소를 유지할 수 있다 |
| 적절한 출발지 변환도 적용하기 | 프록시는 게이트웨이에 피어로서 응답하지만, 이제 원래 클라이언트 대신 변환된 출발지를 본다 |
로그를 예쁘게 만들려고 반환 경로를 확인하지 않은 채 SNAT를 제거하지 마십시오. 널리 적용하면 출발지 ACL과 귀속도 바뀝니다. 그 결과를 설계의 일부로 받아들이십시오.
신뢰할 수 있는 HTTP 홉은 전달 헤더로 클라이언트 메타데이터를 전달할 수 있지만, NAT는 그 헤더를 만들지 않고 TCP 피어 신원으로 바꾸지도 않습니다. Squid로 가는 연결에서 출발지를 보존해도 Squid의 별도 웹사이트 연결에서는 보존되지 않습니다.
마지막으로, 가로채기 설계는 여전히 Squid가 요구하는 목적지 정보를 제공해야 합니다. 대칭 반환 라우팅은 이 시간 초과 메커니즘을 해결할 뿐, 투명 프록시 구성 전체를 해결하지는 않습니다.