Sziasztok
A kliensek átírása nélkül proxyn szeretném átzavarni a http forgalmat, hogy URL szűrést végezhessek.
Napok óta szívok a squiddel Debian 8 alatt.
Első próba: squid proxy, mysql-ből user login. Kliens böngészőbe beírva az IP-t, portot: OK...később jó lehet, most nem ez kell.
Második próba:
Kliensben: iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination PROXY_IP:3128
Távoli szerveren, squid.conf
auth_param basic children 5 startup=1 idle=1
auth_param basic realm Web-Proxy
auth_param basic credentialsttl 1 minute
auth_param basic casesensitive off
visible_hostname localhost.localdomain
#cache deny all
acl all src all
acl localhost src 127.0.0.1/32
acl irodalan src xxxx
http_access allow irodalan
http_access allow localhost
#http_access deny all
http_access allow all
#icp_access allow irodalan
#icp_access allow vhlan
#icp_access allow localhost
#icp_access deny all
dns_nameservers 8.8.8.8
http_port 3129
http_port 3128 intercept
coredump_dir /var/spool/squid3
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
A /var/log/squid3/cache.log-ban:
WARNING: Forwarding loop detected for:
A kliens böngészőben: Hozzáférés megtagadva
Ha nincs ott a http_port 3129, akkor forward-port hiányára panaszkodik.
Mi a gond? Kicsit elvesztem már itt a configokban. A netes leírások legtöbbje korábbi squid kiadásokra épül, melyben lévő szintaktikát már nem kezeli a debian 8-as squid.
Nem ragaszkodom a Squidhez, ha van jobb.
Köszönöm!
- 980 megtekintés
Hozzászólások
Hello,
Nekem így működik a mutatvány. (dansguardiannal tartalmat is szűrök)
iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p tcp --dport 80 -j DNAT --to $PROXY_IP:$PROXY_PORT
- A hozzászóláshoz be kell jelentkezni
De gondolom neked ez a gatewayen van. Nekem a proxy távol van, nem a hálózat része. A megadott iptables sort én a laptopomba írtam be.
- A hozzászóláshoz be kell jelentkezni
Igen, nekem a gateway-en van.
- A hozzászóláshoz be kell jelentkezni
transzparensen igy nem is fog menni, ahhoz mindenkepp a proxy gepen kell a redirect, hogy lassa mi volt az eredeti destination ip. igy ez az info nem jut el a proxyhoz...
- A hozzászóláshoz be kell jelentkezni
Ez mondjuk logikusan hangzik. Köszönöm, kipróbálom így is.
- A hozzászóláshoz be kell jelentkezni
Szerintem a távoli proxy a "Host:" fejlécet figyeli a HTTP kérésben...
--
Debian Linux rulez... :D
RIP Ian Murdock
- A hozzászóláshoz be kell jelentkezni
szerinted
- A hozzászóláshoz be kell jelentkezni
Teszthez simán megadnám a böngészőben a proxy beállításait.
A kliensek automata konfigurálásához WPAD-os rendszert alkalmaznék...
Ha van lehetőséged, akkor tedd az átjáróra a proxy-t vagy irányítsd rá az átmenő HTTP forgalmat.
--
Debian Linux rulez... :D
RIP Ian Murdock
- A hozzászóláshoz be kell jelentkezni
+1
a transparens proxyzassal en meg csak szivast lattam, a mai bongeszok/weboldalak nem szeretik, mert belezavar a cache, keepalive stb mukodesebe, ami foleg az interaktiv ajax-os (facebook es tarsai) oldalaknal gond
masik hogy a forgalom nagyobb resze ma mar https-en megy azt ugyse tudod szurni
A'rpi
- A hozzászóláshoz be kell jelentkezni
Ha jól működik, a kliensek itt elsődlegesen weblapok lesznek, php alkalmazások. A webszerver netre kinyúlását szeretném ezzel korlátozni. Azért nem iptables, mert az elért céldomain IP-je változhat.
- A hozzászóláshoz be kell jelentkezni
Mindehhez azt is hozzá tenném, hogy transzparens proxyn authentikációt kérni nem jó ötlet. Mivel a proxy transzparens, a kliens enm tud róla - ergo, ki is szeretné itt útközben, hogy authentikáljak?!
- A hozzászóláshoz be kell jelentkezni
"...később jó lehet, most nem ez kell."
Kell, de nem most és nem itt. Csupán a működőképességét teszteltem az összeállításnak.
Második próba: config csere és hajrá...elakadtam, itt tartok :)
- A hozzászóláshoz be kell jelentkezni