Travidebla prokura DNAT: kial gravas la revena vojo
Komprenu kial DNAT povas liveri peton al aparta prokuro dum la respondo preterpasas la enirejon kaj rompas la konekton.
Alidirektita SYN povas alveni al Squid dum la kliento ankoraŭ finfine tempolimas. En DNAT-agordo, la revena paketo ankaŭ devas atingi la enirejon, kiu posedas la tradukan staton.
Konsideru ĉi tiun hipotezan 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 directlyLa kliento komence konektiĝis al retadreso. Post DNAT, la prokuro vidas la fonton de la kliento kaj povas uzi la lokan subretan vojon por respondi rekte. Tiu respondo maltrafas la inversan tradukon de la enirejo kaj povas atingi la klienton de la prokura adreso anstataŭ de la atendita retadreso. La enirejo ne povas ripari pakaĵojn, kiujn ĝi neniam ricevas.
| Aliro | Sekvo |
|---|---|
| Konduki la respondojn de la prokuro tra la tradukanta enirejo | La envenanta prokura konekto povas konservi la fontadreson de la kliento |
| Apliki ankaŭ taŭgan fontan tradukon | La prokuro respondas al la enirejo kiel sia kunulo, sed nun vidas tiun tradukitan fonton anstataŭ la origina kliento |
Ne forigu SNAT por pli belaj protokoloj sen kontroli la revenan vojon. Ĝia vasta apliko ankaŭ ŝanĝas fontajn ACL-ojn kaj atribuadon; akceptu tiun sekvon kiel parton de la dezajno.
Fidinda HTTP-salto povas transdoni klientajn metadatenojn en plusenda kaplinio, sed NAT ne kreas tiun kaplinion nek igas ĝin TCP-kunula identeco. Konservi fonton en la konekto al Squid ankaŭ ne konservas ĝin en la aparta reta konekto de Squid.
Fine, la interkapta dezajno ankoraŭ devas provizi la celinformon, kiun Squid postulas. Simetria revena enkursigo solvas ĉi tiun tempoliman mekanismon, ne la tutan agordon de travidebla prokuro.