On 15.03.2012 08:03, Mustafa Raji wrote:
hi
still the problem of invalid request problem exist in my caches
server, i will explain this problem with more deletes here hopping
there is some thing i don't know about in squid solve this problem
as a trying i did capturing to the invalid request and the captured
packet deletes is
Frame 4139: 110 bytes on wire (880 bits), 110 bytes captured (880
bits)
Arrival Time: Mar 13, 2012 11:53:02.536140000 AST
Epoch Time: 1331628782.536140000 seconds
Time delta from previous captured frame: 0.008177000 seconds
Time delta from previous displayed frame: 0.008177000 seconds
Time since reference or first frame: 51.377354000 seconds
Frame Number: 4139
Frame Length: 110 bytes (880 bits)
Capture Length: 110 bytes (880 bits)
Frame is marked: False
Frame is ignored: False
Protocols in frame: eth:ip:tcp:http:data
Coloring Rule Name: HTTP
Coloring Rule String: http || tcp.port == 80
Internet Protocol, Src: 192.168.40.3 (192.168.40.3), Dst:
10.10.10(10.10.10.53)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 96
Identification: 0x23e0 (9184)
Flags: 0x02 (Don't Fragment
Fragment offset: 0
Time to live : 127
Protocol : TCP (6)
Header checksum: 0xdacd [correct]
source 10.10.10.53 (10.10.10.53
Destination: 192.168.40.3 (192.168.40.3)
Transmission Control Protocol, Src Port:49869 (49869), Dst Port: http
(80), seq:
Source port: 49869 (49869)
Destination port: http (80)
[Stream index: 240]
Sequence number: 1 (relative squence number)
[NEXT squence number: 57 (relative sequence number)]
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
window size: 17520 (scaled)
Checksum: 0xba28 [validation disabled]
[SEQ/ACK analysis]
*Hypertext Transfer Protocol
*DATA (56 bytes)
Data:0569ff24fdd6dbd18ffe4d2f2fffaa9020alae217a53923a..
[Length: 56]
the squid is recognize the ips of the client in the access.log file,
the policy routing in mikrotik done using the dstnat rule, what ever
You seem to be confusing the two systems.
"NAT" is NAT or NAPT maybe both, (*address translation*).
Policy routing is a type of routing (*packet delivery*).
They are not the same. Routing cannot do NAT and NAT cannot do routing.
No more than a postman can change the street your house is on, or the
house you live in can delivery peoples mail.
NAT is like the postman who changes the erases address on the letters
with his friends address then puts them back in a post box.
Please get that straight. You have managed to get it "working" (sort
of) because of some security vulnerabilities in Squid and HTTP, but it
will break when anything involving those security holes changes ...
packets comes from any source ip address except the ip of the cache
server in the tcp port at port 80 is distend to the ip address of the
cache port 80
to be a clear it's the same as this linux rule
this rule is for clearance not applied in the linux iptables (because
i don't know who to explain to you what i did in mikrotik router)
iptables -t nat -A PREROUTING -p tcp --dport 80 ! -s 192.168.40.2 -j
DNAT --to-destination 192.168.40.2:80
where 192.168.40.2 is the ip of the cache server
if the problem is with sending ssl request to the cache server
through the 80 port but why this happening this type of traffic
should
work on port number 433 so the mikrotik rule does not applied for
this
type of traffic
What do you mean? You have found some software abusing port 80 to try
and sneak things past your firewall security system? Squid breaking such
abusive things is *good*.
NOTE:
- traffic *MUST NOT* be sent by browsers etc to the proxy on port 80.
There is port 3128 for proxy traffic (maybe others >1024 if you want).
- SSL+HTTP native traffic *MUST NOT* be sent on port 80 either. It
goes on port 443.
- SSL traffic (any kind) *MAY* be sent to the proxy on port 3128 so
long as it is wrapped in a special plain-HTTP CONNECT request.
So what is the problem?
Amos
