proxy mögött netmegosztás

Debian GNU/Linux

Sziasztok!

Helyzet:

Adott egy céges hálózat. Sok-sok gép, internet elérés proxyn keresztül. A gépek dhcp-vel kapják a címeket, de ahol net is jár, ott kézzel be van varrva a böngészőbe a proxy címe (xxx.xxx.xxx.xxx:3128).
Létrehoztunk egy net eléréses Debian Sarge-os "telepítő" gépet, amelyben az eth0 a céges láb, az eth1 (192.168.99.1) az a láb, amelyre az éppen szerelendő gépeket dugjuk. Az eth0-s netet osztjuk eth1-nek is. Az eth1 oszt címet, mindig ugyanazt. (192.168.99.2)

Probléma:

Az eth1-en jön a net, de csak abban az esetben, ha a céges proxyt is megadjuk a böngészőkben. Úgy lenne az igazi, hogy csak rádugnánk a telepítendő gépet a Debianra, kapna egy fix címet és már menne is a net. De így nem működik. A címet megkapja (192.168.99.2), pingálni tudunk kifelé, de a proxy nélkül nem jön az internet.

Mi lehet a gáz? A szerelendő gépnek egyáltalán ki legyen a nameservere?

Köszi!

ace

  • 1769 megtekintés

( efpe | 2006. 05. 23., k – 11:30 )

a sarge-os routerra csinalj bind-ot, az legyen a nameserver, es egy iptables sorral forwardold a 80-as portra erkezo kereseket a proxy ip:port-jara.

( Dr_Mac | 2006. 05. 23., k – 11:41 )

Ez szerintem routolási probléma. Ugyanis ha a böngészőbe be van írva a proxy címe, akkor ugye értelemszerűen mennek a csomagok a proxyn keresztül. Viszont ha ez nincs, akkor a csomag elakad valahol a proxy belső lábán. Érdemes a proxyn egy iptables szabályt felállítani, ami az összes belülről jövő webre irányuló forgalmat (destination port 80) átirányítja a proxy belső címének 3128-as portjára.

( zolo | 2006. 05. 23., k – 12:41 )

tudni kene arrol is, hogy a halozat hogy van kialakitva.
mert teszem azt DMZ-ben van a proxy szervered, es a LANrol kozvetlenul nem mehetsz ki, akkor bizony csak proxyn keresztul fog menni.
Alapbol nyilvan a kliens proxy nelkul kozvetlennek tekinti az elerest, es a gatewayen keresztul menne ki, amit ugye tuzfal letilt.
Csak DHCP-n keresztul nem fogsz ilyen jellegu beallitast kapni marad valami logon script, ami a te esetedet nem konnyiti meg, ergo felesleges.
szerelendo gep meg dhcptol kap dns szerver cimet is...

( freebush | 2006. 05. 23., k – 13:11 )

én is arra gondoltam, a tűzfal nem enged ki a 80-as porton...
Próbálj meg Lynx-szel netezni, ha neki sem megy, akkor szvsz tűzfal lehet.

( ace | 2006. 05. 24., sze – 12:44 )

Sziasztok!

Bocsi, de befutott egy sürgős meló, de mostmár újra foglalkozom a témával.

Bind-ot felraktuk, névfeloldás megy rendesen de böngészni nem lehet. Beírom www.hup.hu és utána az a hibaüzenet, hogy

ERROR
The requested URL could not be retrieved
While trying to retrieve the URL: /
Invalid URL
...

A proxy szerverhez (192.168.xxx.1) nincs hozzáférésünk, úgy van beállítva, ahogy, nem tudjuk.

A INPUT,OUTPUT,FORWARD egyelőre ACCEPT.
Config részlet:

...
$IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE

$IPTABLES -t nat -A PREROUTING -i eth1 -p TCP --dport 80 -j DNAT --to 192.168.xxx.1:3128
$IPTABLES -t nat -A PREROUTING -i eth1 -p UDP --dport 80 -j DNAT --to 192.168.xxx.1:3128

#$IPTABLES -t nat -A PREROUTING -p UDP --dport 80 -j REDIRECT --to-ports 3128
#$IPTABLES -t nat -A PREROUTING -p TCP --dport 80 -j REDIRECT --to-ports 3128

echo "1" > /proc/sys/net/ipv4/ip_forward
...

Tcpdump próbálkozások mindkét lábon a www.hup.hu-ra:
______________________________________
tcpdump -i eth1 -n port 80 or port 3128

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
12:34:06.493992 IP 192.168.99.2.1127 > 195.228.252.138.80: S 2403648848:2403648848(0) win 16384
12:34:06.494924 IP 195.228.252.138.80 > 192.168.99.2.1127: S 3055034763:3055034763(0) ack 2403648849 win 5840
12:34:06.495031 IP 192.168.99.2.1127 > 195.228.252.138.80: . ack 1 win 17520
12:34:06.495367 IP 192.168.99.2.1127 > 195.228.252.138.80: P 1:512(511) ack 1 win 17520
12:34:06.495810 IP 195.228.252.138.80 > 192.168.99.2.1127: . ack 512 win 6432
12:34:06.497954 IP 195.228.252.138.80 > 192.168.99.2.1127: P 1:1123(1122) ack 512 win 6432
12:34:06.498420 IP 195.228.252.138.80 > 192.168.99.2.1127: F 1123:1123(0) ack 512 win 6432
12:34:06.498513 IP 192.168.99.2.1127 > 195.228.252.138.80: . ack 1124 win 16398
12:34:06.549369 IP 192.168.99.2.1127 > 195.228.252.138.80: F 512:512(0) ack 1124 win 16398
12:34:06.549688 IP 195.228.252.138.80 > 192.168.99.2.1127: . ack 513 win 6432
______________________________________

tcpdump -i eth0 -n port 80 or port 3128

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:35:56.162846 IP 192.168.xxx.41.1129 > 192.168.xxx.1.3128: S 2431099147:2431099147(0) win 16384
12:35:56.163261 IP 192.168.xxx.1.3128 > 192.168.xxx.41.1129: S 3177030989:3177030989(0) ack 2431099148 win 5840
12:35:56.163441 IP 192.168.xxx.41.1129 > 192.168.xxx.1.3128: . ack 1 win 17520
12:35:56.196130 IP 192.168.xxx.41.1129 > 192.168.xxx.1.3128: P 1:512(511) ack 1 win 17520
12:35:56.196494 IP 192.168.xxx.1.3128 > 192.168.xxx.41.1129: . ack 512 win 6432
12:35:56.198622 IP 192.168.xxx.1.3128 > 192.168.xxx.41.1129: P 1:1123(1122) ack 512 win 6432
12:35:56.199073 IP 192.168.xxx.1.3128 > 192.168.xxx.41.1129: F 1123:1123(0) ack 512 win 6432
12:35:56.199245 IP 192.168.xxx.41.1129 > 192.168.xxx.1.3128: . ack 1124 win 16398
12:35:56.200046 IP 192.168.xxx.41.1129 > 192.168.xxx.1.3128: F 512:512(0) ack 1124 win 16398
12:35:56.200215 IP 192.168.xxx.1.3128 > 192.168.xxx.41.1129: . ack 513 win 6432
______________________________________

Az Ethereallal elemeztük és kidobott egy ilyet:

...
HTTP/1.0 400 Bad Request\r\n
Server: Squid/2.
[Packet size limited during capture: HTTP truncated]
...

Na ez mi lehet?