Mam problem z bardzo prostą konfiguracją kałamarnicy.
Moja sieć jest skonfigurowana tak, jak pokazano:
=== 192.168.3.xxx LAN === (eth1 - .100) [host proxy] (. 18.240.66 - eth0) === 10.xxx LAN
Chcę przesyłać żądania proxy z sieci LAN 192.168.3.0/24 do sieci LAN 10.0.0.0/8. Skonfigurowałem ustawienia proxy na 192.168.3.200, aby używać proxy na 192.168.3.100:8080. Prośba o proxy przychodzi do proxy, ale wydaje się, że nie wychodzi z eth0. Oba zweryfikowałem za pomocą Wireshark.
W szczególności próbuję wysłać żądanie HTTP z 192.168.3.200 do 10.63.78.243 za pośrednictwem proxy. Oto co kończy się w kałamarnicy access.log:
192.168.3.200 TCP_MISS/000 0 GET http://10.63.78.243:8080/path/server.jsp? - DIRECT/10.63.78.243 -
Pakiet wysłany z .200 na .100: 8080 ma następującą zawartość (przez Wireshark):
GET http://10.63.78.243:8080/path/server.jsp?x=x HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1; MS-RTC LM 8)
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive
Host: 10.63.78.243:8080
Mam następującą konfigurację kałamarnicy:
#
# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl RDnet dst 10.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
http_access allow RDnet
# And finally deny all other access to this proxy
http_access deny all
# Squid normally listens to port 3128
http_port 8080
# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?
# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256
# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid
# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
netstat -rn daje następujące:
[root@localhost squid]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
10.18.240.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 10.18.247.254 0.0.0.0 UG 0 0 0 eth0
Czytam to jako routing dowolnego pakietu (w tym tych do 10.63.78.243) do 10.18.247.254 przez eth0. Wiem, że jest osiągalny (zobacz ten wynik ping -R)
[root@localhost squid]# ping -c 1 -R 10.63.78.243
PING 10.63.78.243 (10.63.78.243) 56(124) bytes of data.
64 bytes from 10.63.78.243: icmp_seq=1 ttl=50 time=377 ms
RR: 10.18.240.66
10.138.156.186
10.17.182.22
10.190.11.66
112.78.255.4
198.19.1.41
10.143.222.81
10.143.222.98
172.31.206.129
--- 10.63.78.243 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 377ms
rtt min/avg/max/mdev = 377.644/377.644/377.644/0.000 ms
jakieś pomysły? Jedną z moich myśli jest to, że Squid dobrze odbiera żądanie i próbuje je wysłać, ale ... Gdzie to może być? Ten host ma tylko 2 interfejsy, a pakiety do 10.xxx powinny wychodzić eth0. Ale żaden pakiet nie pojawia się w Wireshark. Więc jestem trochę zagubiony.
AKTUALIZACJA: Dodano następujące informacje do pliku konfiguracyjnego:
cache_peer 10.159.3.23 parent 8080 0 default
Dzięki temu mój serwer proxy mógł przekazywać żądania do serwera proxy, który faktycznie może dotrzeć do hosta 10.63.78.243.
cache_peer 10.159.3.23 parent 8080 0 defaultOdpowiedzi:
MISS / 000 oznacza przerwanie, brak pewności, że pochodzi od klienta lub brak odpowiedzi po przekazaniu żądania do 10.63.78.243:8080
Co otrzymujesz z „telnet 10.63.78.243 8080” od hosta kałamarnicy? Host GET / HTTP / 1.1: 10.63.78.243:8080
źródło