Meg annyi, hogy a zone lookup ipv6 eseten nem tunik jonak: # kzorp -e tcp 2a01:368:e001:0:12c5:86ff:feba:84a8 6666 2a01:270:91e8:fd:195f:db38:31c9:c9ec 143 eth0 evaluating 2a01:368:e001:0:12c5:86ff:feba:84a8:6666 -> 2a01:270:91e8:fd:195f:db38:31c9:c9ec:143 on eth0 Client zone: internet Server zone: internet Service: not found Dispatcher: not found ipv4 (ez igy mukodik is kiprobalva telnettel): # kzorp -e tcp 44.128.156.173 6666 88.151.99.232 143 eth0 evaluating 44.128.156.173:6666 -> 88.151.99.232:143 on eth0 Client zone: inside Server zone: internet.end.re Service: PF_inside_IMAP_internet.end.re Dispatcher: SA(proto=1,addr=AF_INET6(::1:50143)) udv, Endre -- 2012/6/9 Endre Szabo <zorp-hu@end.re>:
Sziasztok,
1) Annyira nem mukodik jol a kzorp ebben nekem. Sima userpsace proxy-s Service-ket nem indit, csak PFService-ket. A jelenseg az, hogy latszolag a kzorp elnyeli a csomagot logolas nelkul, zorp processt stracelve nem latom, hogy megkapna, netfilter mangle prerouting KZORP target utan nyoma vesz a SYN csomagoknak. Ez a setup amugy mukodik ha az NDimensionDispatchet PFServicet hivogat. Ez a helyet csak ipv4 eseteben van igy, ipv6-nal megamugy nem tortenik semmi (packet loss log nelkul, akar Service, akar PFService), bar lehet, hogy az ipv4-es directed router dest_addr miatt van ez (ipv6->ipv4 atjarhatosag? sima nontransparent listenerrel mukodik).
2) Meg erdekesseg, hogy directedrouter SockAddrInet6 tipusu dest_addr eseteben nem mukodik, 'kzorp -s' is dob egy szep tracet, mert valoszinoleg v4 cimet varna a kzorptol.
3) iptables-save is bugos, egybeirja a KZORP targetet annak parameterevel:
"-A POSTROUTING -j KZORP--tproxy-mark 0x80000000/0x80000000" ...