Squid Reverse Proxy url regex

Web, mail, IRC, IM, hálózatok

Üdvözletem,

FreeBSD-n használok squid-et (3.2.5) reverse proxynak.
Szeretném elérni hogy www.domain.com és www.dom.com-al ellentétben www.domain.com/foo -t és www.dom.com/foo -t másik webszerveren keresse.

vonatkozó config:
cache_peer 10.6.6.13 parent 86 0 no-query originserver name=server_7
cache_peer_domain server_7 foo.domain.com foo.dom.com

acl server_7 url_regex ^http://www.domain.com/foo
cache_peer_access server_7 allow foo
cache_peer_access server_7 deny all

acl Safe_ports port 86 # foo

viszont ez nem volt célravezető sajnos. Gyakorlottabb kollégák tanácsát kérem arra vonatkozólag, hogyan is oldhatnám meg ezt a feladatot.
A konstruktív hozzáállást köszönöm!

  • 10668 megtekintés

( jupiter2005ster v | 2014. 03. 22., szo – 08:00 )

szerintem ilyen szintű forgalomirányítást a squid nem tud. mi .pac fájl-t készítettünk amivel a felhasználók a jó helyre mennek.

bár lehet hogy ez a 'name=server_7' ez 3.2.5 fícsör. mi még a régi 3.1 verziót nyúzzuk CentOS 6-on.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Valószínüleg új feature, mivel upgradelnem kellett ahhoz hogy ez működőképes direktíva legyen.

Egyébként ez alapján próbáltam meg http://wiki.squid-cache.org/ConfigExamples/Reverse/MultipleWebservers
viszont az a helyzet az hogy url regex-sem működik. Tudom hogy az sokkal veszélyesebb, hiszen nemcsak domain.com/valami hanem domain.com/akarmi/valami is illeszkedik rá, de próbának megtette volna.

Lehet rosszul fogalmaztam meg mit is szeretnék elérni. Webserver szempontból egyes könyvtárakban "domain.com/valami/akarmi" különböző cms-ek üzemeltetése a cél, ezt megfejelni azzal, hogy ezek különböző jailekben vannak (domain.com, valami, akarmi), és mindezt úgy, hogy 2 domain -en legyen elérhető a dolog. Ezért gondoltam, hogy "urlregex" működhet.

Ennek a .pac -nak utánanézek. Köszönöm!
-

acl server_7 url_regex ^http://www.domain.com/foo

hm... azt hiszem tudom miért nem működik. ha regex-t használsz akkor ott sor illeszkedést néz a rendszer, legalább is Perl, Python és a Bash azt teszi. nos hogy ha az URL-ed http://www.domain.com/foo?.... már nem is illeszkedik. tegyél utána egy .* valahogy így
....foo.*
a .* a bármi akárhányszor reguláris leírása.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

( jupiter2005ster v | 2014. 03. 22., szo – 08:18 )

de ha már itt tartunk engem is nagyon érdekelne hogy .pac fájl nélkül hogy lehet a squidel megcsinálni hogy ezeket a domain címeket erre, ezeket meg amarra küldje. pl, ha IP akar vlaki elérni akkor az azt a LAN-on belül marad, ha xyz.com akkor az is de a zzzz.com már meg kifelé.
én úgy tudom h az összes beérkező kérést továbbítja az internet felé.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

( zolo | 2014. 03. 22., szo – 17:18 )

esetleg igy?

http_port 80 accel defaultsite=www.domain.com vhost
forwarded_for on
cache_peer 10.6.6.13 parent 80 0 no-query originserver name=server_7 #vagy cache_peer vagy cache_peer_domain!
acl urlreg1 url_regex ^http://www\.domain\.com/foo/.*$

cache_peer_access server_7 allow urlreg1
cache_peer_access deny all

http_access allow urlreg1

Kell hozzá ProxyPassReverse... is. Amúgy a reverse proxy azért se triviális, mert függ attól, hogy milyen web oldal, vagy webes alkalmazás van az átirányítandó web szervereken. Pl. a Proxmox 3.0 Web UI-ját nem lehetett bekorlátozni a proxy egy alkönyvtárába, mert az alkalmazásba fixek voltak a hivatkozások a szerver gyökerétől, ezért a proxy kívánt alkönyvtára (pl. /foo) mellett a proxy más könyvtárait is (pl. /prglib) is a proxmox szerverre kellett reverse proxy-zni, hogy működjön. Emiatt pl. két proxmox Web UI-t valószínűleg nem lehet azonos proxy szerver két "könyvtárán" keresztül elérni.
--
Légy derűs, tégy mindent örömmel!

Most lett időm vele foglalkozni, ezért megpróbálom beüzemelni a javasolt apache proxy-t, egyelőre addig jutottam hogy ugyanúgy "átenged", tehát /foo query esetén nem irányít át a foo.valami.com backend serverre, hanem simán az eredetin kajtat. Biztosan elnéztem valamit. Ugyanakkor az is lehet hogy az appserver előtt lévő squid bekavar, de hát valahogy mégiscsak meg kell neki mondanom, hogy akkor most az apache proxy a főnök. Gondoltam ráirányítom a forgalmat, és akkor kész is -hát nem. Na akkor a móka folytatódik pénteken.

-

Mi is a pontos kérdés?
Ez?
"Szeretném elérni hogy www.domain.com és www.dom.com-al ellentétben www.domain.com/foo -t és www.dom.com/foo -t másik webszerveren keresse. "

Squid-el meg lehet oldani, mindent :)
Röviden a fentebbire a megoldás:
## ez a két kiszolgálószerver (webszerver)
cache_peer 5.6.7.8 parent 80 0 no-query no-digest originserver name=peer_domain_foo
cache_peer 1.2.3.4 parent 80 0 no-query no-digest originserver name=peer_domain_com

## a foo acl a /foo url-esre illeszkedni fog. A regexp-et szépítsd még, ez csak a minimum
acl foo url_regex http://www\.domain\.com/foo
acl foo url_regex http://www\.dom\.com/foo

## domain-es acl
acl dom dstdomain www.domain.com
acl dom dstdomain www.dom.com

## az 5.6.7.8-as IP-s cache_peer-re engedjük a foo-s acl-re illeszkedő kéréseket, a többit tiltjuk
cache_peer_access peer_domain_foo allow foo
cache_peer_access peer_domain_foo deny all

## a dom acl-re illeszkedő kéréseket az 1.2.3.4-es IP-re továbbítjuk, mást tiltunk
cache_peer_access peer_domain_com allow dom
cache_peer_access peer_domain_com deny all

Amire figyelj, az a cache_peer sorok sorrendje! Nem a cache_peer_access sorrendje számít, hanem a cache_peer-ek sorrendje. Mivel a www.domain.com/foo illeszkedik a dom-os acl-re is (dstdomain www.domain.com) ezért ha az a cache_peer van először, akkor arra fog beesni, nem pedig arra amelyikre szeretnéd.

( zsolt | 2014. 04. 03., cs – 20:32 )

Redirector scriptet kell írnod. A squid elindítja a scriptedet, stdin-jére írja a bejövő kéréseket, a scriptednek azokra válaszként kell írni stdout-ra, hogy milyen URL-ről szolgálja ki őket. Elég egyszerű, van rá példa is a doksiban és a forráscsomagban is.
A scriptet külön processzként indítja, így bármilyen programnyelven megírhatod.

Bocs, hogy nem vettem észre a válaszodat, tényleg jó a config, de egyszerűbbnek azért nem mondanám. KB 10 éve volt egy munkám, amiben redirectorral oldottam meg hasonlót, bár ott a redirector egy TCP porton is figyelt, hogy kívülről lehessen tölteni az URL-átírási szabályokat. Azóta nem foglalkoztam squid-del, úgyhogy még egyszer elnézést.

( Rt711 v | 2014. 04. 09., sze – 12:51 )

Köszönöm mindenkinek a konstruktív hozzáállást és a türelmet.
A problémát végülis a felvetett apache proxyval oldottam meg, melyet ma végre volt időm értelmezni.

ServerName domain.com

ProxyPreserveHost on
ProxyPass /foo http://IP/
ProxyPassReverse /foo http://IP/
ProxyPass / http://www.domain.com/
ProxyPassReverse / http://www.domain.com/

Biztosan megoldható squid-el is a dolog, de mivel ez sokkal egyszerűbb, és a configot később is nem csak nekem hanem másoknak is gyorsan kell tudnia alkalmazni, ez lett a célszerű választás.
-