Dlaczego dostęp do drugiej sieci LAN (przez kałamarnicę) nie działa?

0

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.

Fan Cubs Ron
źródło
literówka w tekście - mówi „Próbuję wysłać żądanie HTTP od 192.168.3.200 do 110.63.78.243 za pośrednictwem proxy”, ale ten adres docelowy powinien wynosić 10 .63.78.243, a nie 110 .xxx (AKTUALIZACJA: zaktualizowano w pytaniu )
Fan Cubs Ron
Mam pewną myśl - być może muszę dodać interfejs, którego potrzebują pakiety 10.xxx do konfiguracji kałamarnicy. Próbowałem uruchomić lokalnego klienta Firefox na maszynie „hosta proxy” z konfiguracją, która nakazała mu korzystanie z serwera proxy i podobnie się nie udało. Wskazuje na tego rodzaju informacje o konfiguracji ???
Cubs Fan Ron
@Card dał mi podpowiedź poniżej - dodałem następujący wiersz do pliku konfiguracyjnego, aby umożliwić mojemu serwerowi proxy przekazywanie do innego serwera proxy, który faktycznie może dotrzeć do hosta, do którego próbuję dotrzeć! cache_peer 10.159.3.23 parent 8080 0 default
Cubs Fan Ron

Odpowiedzi:

0

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

Karta
źródło
Cóż, to nie działało, ale jeśli spróbowałem załadować stronę internetową w Firefoksie z tego samego hosta, to zadziałało. Znać różnicę? Firefox użył serwera proxy!
Cubs Fan Ron
Dokonałem zmiany konfiguracji i wymieniłem powyżej. Nie dałeś mi odpowiedzi, ale zdecydowanie mnie do tego doprowadziłeś. To mi wystarczy - zdobywasz +1 i znacznik wyboru!
Cubs Fan Ron
(Nie mam jeszcze chwały, aby dać ci +1, ale kiedy to zrobię, wrócę i to zrobię)
Cubs Fan Ron
Dzięki ^^, zauważyłem dziś rano, że serwer dst nie jest podłączony do podsieci interfejsu proxy, ten punkt prowadzi do wielu innych możliwych problemów, takich jak przekazywanie proxy, routing lub blokowanie FW ..
Karta