Sziasztok!
Utolsó kérdés proxyügyben:
Képes-e a squid arra, hogy ugyanazon a porton működjön forward ("normál") proxyként és reverse (accelerator) proxyként? Alapvetően forward proxyként akarom használni, csak annyit szeretnék, hogy ezen felül néhány statikus fájlt le lehessen tölteni rőle sima HTTP (nem proxy-specifikus kérésekkel).
Először megpróbáltam, hogy sima forward üzemmódba kapcsolom az adott http portot, és rewrite parancsokkal megpróbálom rávenni, hogy ha olyan GET kéréssel fordul hozzá a böngésző, ahol az első sorban nem teljes URL van, csak fájlnév, akkor is próbálja meg elirányítani egy forrásszerverre, de a squid visszautasította, mondván ez egy bad request.
Ezután megadtam egy defaultsite paramétert a http portra, amitől automatikusan accelerator módba kapcsolt, és a böngésző proxy-specifikus kéréseire nem forward proxyként válaszolt: A CONNECT metódusú kéréseket simán visszautasította, a teljes URL-eket lekérő GET kérésekre pedig azt adta vissza, hogy "permanently moved".
Ennyi alapján tehát úgy tűnik, hogy a squid nem támogatja a szimultán forward+reverse proxy működést. A doksijában is csak annyit találtam, hogy lehetséges lenne ugyan ilyen jellegű működés, de nem nagyon foglalkoznak a megvalósításával, hogy a kód egyszerű maradhasson.
Nem tudom, sikerült-e valakinek kicsiholni belőle legalább egy minimális reverse proxy működést az alapvető forward üzemmód mellett?
- 4524 megtekintés
Hozzászólások
- A hozzászóláshoz be kell jelentkezni
Egy konfigfájllal is viselkedhetne két különböző funkciójú példányként, de csak két különböző porton. Én pedig azt szeretném, hogy ugyanazon a porton produkálja a kétféle viselkedést :-(
- A hozzászóláshoz be kell jelentkezni
Ez a két dolog teljesen máshogy működik, miközben ugyanazt a protokollt (HTTP) használják, így a program nem tudná eldönteni, hogy most akkor melyik legyen.
- A hozzászóláshoz be kell jelentkezni
Szerintem nem működik nagyon máshogy. A sima és a proxy lekérdezés majdnem pontosan ugyanolyan. Éppen csak annyi különbség van köztük, ami alapján el tudná dönteni a squid, hogy milyen lekérdezésről van szó:
Sima lekérdezés:
GET / HTTP/1.1
Host: hup.hu
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: hu-hu,hu;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: MÉG_MIT_NEM
Connection: keep-alive
If-Modified-Since: Fri, 08 Aug 2014 20:08:43 GMT
Proxyn keresztüli lekérdezés:
GET http://hup.hu/ HTTP/1.1
Host: hup.hu
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: hu-hu,hu;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: MÉG_MIT_NEM
Connection: keep-alive
If-Modified-Since: Fri, 08 Aug 2014 20:08:43 GMT
Amint látod, csak az első sor különbözik.
- A hozzászóláshoz be kell jelentkezni
Megpróbáltam a Chrome-ot a következő módon meghívni, hátha rá tudom venni, hogy a PAC fájlt a proxy szerveren keresztül töltse le, majd feltétel nélküli proxyhasználat helyett átálljon a benne foglalt utasítások végrehajtására:
google-chrome --proxy-server=http://proxy.dns.neve:3128 --proxy-pac-url=http://web.szerver.neve/proxy.pac http://web.oldal
De nem jártam sikerrel. A Chrome semmivel sem törődve közvetlen kapcsolattal tölti le a PAC fájlt. Mondjuk már az is megoldaná a problémát, ha a GET parancs sorába teljes URL-t írna path helyett a PAC fájl letöltésekor, de nem...
- A hozzászóláshoz be kell jelentkezni
Ööööö... wget -> fájl -> pac fájlból?
- A hozzászóláshoz be kell jelentkezni
Köszi, ez sem elvetendő ötlet. Ha fut Windows alatt, és képes jelszóval védett és/vagy SSL-titkosított proxyn keresztül letölteni, akkor OK. Majd utánanézek.
- A hozzászóláshoz be kell jelentkezni
Squid követelmény?
Félve írom, mert sohasem használtam és lehet, hogy csak a doksit értettem félre, amikor belenéztem proxyt keresve, de mintha az apache+mod_cache tudna ilyet.
- A hozzászóláshoz be kell jelentkezni
Köszi, majd megnézem. Szóba jöhet, ha képes SSL-titkosított forward proxyként Active Directoryból authentikálni. Egyszer írtam hozzá egy helper szkriptet amivel weboldalakat tud AD authentikációval védeni; ha ez újrahasznosítható lenne forward proxy üzemmódhoz, akkor jó lehet. Most viszont két hét szabira mentem és inkább nem görcsölök vele :-)
- A hozzászóláshoz be kell jelentkezni