Linux за българи: Форуми

Опитвам се да се логна в една ($2) страница която има явно java captcha, но заради squid-а, captcha-та изобщо не се вижда. Опитах да добавя гугълския линк google.com/recaptcha/api2/ , както и:

# bypass proxy authentication for a User Agent of Java app ($2)
acl Java browser Java/1.4 Java/1.5 Java/1.6  Java/1.7  Java/1.8  Java/1.9
http_access allow Java

, но без успех. Някой с друга идея?

Не можеш ли да изключиш тоя домейн да НЕ минава през squid-а ?

Колегата май бърка Java с Javascript - никой не иска капча която няма да работи на повечето браузъри... най-малкото пък Гугъл - при тях на по-новите версии на хрома с новия plug-in формат Джавата въобще не тръгва ($2) (ама и май го направиха това не тръгване и малко нарочно след като Оракъл ги осъдиха за неправилна употреба на Java API ама това е една друга тема)

Проблемът по-скоро може да е от HTTPS - там squid въобще не знае какво става вътре, но виж в журнала дали няма грешка при отварянето на HTTPS или пък не му е забранено въобще HTTPS.

- също така е желателно да се забрани кеширането на reCaptcha трафика т.е. pass-through
- и още една идея: освен клиента който влиза също и сървъра отсреща (non reCpatcha) който го валидира трябва да вижда reCaptchata през тоя squid.
- и за финал: FirewallsAndRecaptcha ($2)

П.П. Извинявам се ако аз не съм рабрал правилно... ако случайно ти си правил страницата т.е. и клиента и сървъра, като сървъра ти е на джава която не може да пробие навън тогава може би нещо такова ще оправи нещата:

iptables -t filter -s $server -m tcp -p tcp --dport 80 -j REDIRECT --to-port 3128 --to-destination $squidserver

on either the $server that's generating the requests or the firewall that's dropping the packets?

TL;DR ($2)
# My networking guys are telling me, we need to some how call this
# request through the proxy server so it can go through or we would have
# to open up all of google through the firewall.

Не можеш ли да изключиш тоя домейн да НЕ минава през squid-а ?

Може, ако има кой да се сети :) Мерси

Колегата май бърка Java с Javascript - никой не иска капча която няма да работи на повечето браузъри... най-малкото пък Гугъл - при тях на по-новите версии на хрома с новия plug-in формат Джавата въобще не тръгва ($2) (ама и май го направиха това не тръгване и малко нарочно след като Оракъл ги осъдиха за неправилна употреба на Java API ама това е една друга тема)

Проблемът по-скоро може да е от HTTPS - там squid въобще не знае какво става вътре, но виж в журнала дали няма грешка при отварянето на HTTPS или пък не му е забранено въобще HTTPS.

- също така е желателно да се забрани кеширането на reCaptcha трафика т.е. pass-through
- и още една идея: освен клиента който влиза също и сървъра отсреща (non reCpatcha) който го валидира трябва да вижда reCaptchata през тоя squid.
- и за финал: FirewallsAndRecaptcha ($2)

П.П. Извинявам се ако аз не съм рабрал правилно... ако случайно ти си правил страницата т.е. и клиента и сървъра, като сървъра ти е на джава която не може да пробие навън тогава може би нещо такова ще оправи нещата:

iptables -t filter -s $server -m tcp -p tcp --dport 80 -j REDIRECT --to-port 3128 --to-destination $squidserver

on either the $server that's generating the requests or the firewall that's dropping the packets?

TL;DR ($2)
# My networking guys are telling me, we need to some how call this
# request through the proxy server so it can go through or we would have
# to open up all of google through the firewall.

Да, скрипта имах предвид.
Няма нищо по логовете за https-а, първо това проверих. Сега ще погледна за кеширането, но явно тази опция ще отпадне, защото няма опция да се даде достъп до google-ските ИП-та.
Мерси все пак за линковете, поне се поосведомих.

П.С. Правилно си разбрал ;)

EDIT:

Добавих изключението ($2), но нещо не работи:

GeSHi (Bash):
SQUID 3.x	
acl hotmail dstdomain .hotmail.com
always_direct allow hotmail

# /usr/local/sbin/squid -v
Squid Cache: Version 3.5.9
Service Name: squid

Лога от squid-а:

GeSHi (Bash):
1450338872.287   5032 192.168.1.36 TCP_TUNNEL/200 363 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1450338872.507   8644 192.168.1.36 TCP_TUNNEL/200 11074 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1450338898.354  30670 192.168.1.36 TCP_TUNNEL/200 16155 CONNECT www.google-analytics.com:443 - HIER_DIRECT/216.58.208.110 -

Е ама ти си го преписал дословно от примера
на теб колегата ти каза НЕ за домейна hotmail.com ами ЗА google.com
...доколкото разбрах
а аз бих добавил също и  (като ти гледам журнала)
google-analytics.com

П.П. Според мен тази директива always_direct ($2) не е точно това което търсиш - тя по скоро указва да не се минава през друго прокси/squid, но какво му пречи да си го извади от собствения си кеш...
според мен правилната директива е по-скоро no_cache
т.е. cache/no_cache комбинация

и правилните линкове са тези:
Can I make Squid go direct for some sites? ($2) - този не ти трябва (той както е обяснено е за други цели)

Can I make Squid proxy only, without caching anything? ($2) - виж това може да свърши работа.

#примерна постановка:
acl google dstdomain .google.com
cache deny google

като внимаваш на преден ред да нямаш cache allow all
т.е. реда на диретивите е важен във файла - обик. политиката е
cache allow ...
cache allow ...
cache deny all
или обратно
cache deny ...
cache deny ...
cache allow all

Е ама ти си го преписал дословно от примера
на теб колегата ти каза НЕ за домейна hotmail.com ами ЗА google.com
...доколкото разбрах
а аз бих добавил също и  (като ти гледам журнала)
google-analytics.com

П.П. Според мен тази директива always_direct ($2) не е точно това което търсиш - тя по скоро указва да не се минава през друго прокси/squid, но какво му пречи да си го извади от собствения си кеш...
според мен правилната директива е по-скоро no_cache
т.е. cache/no_cache комбинация

и правилните линкове са тези:
Can I make Squid go direct for some sites? ($2) - този не ти трябва (той както е обяснено е за други цели)

Can I make Squid proxy only, without caching anything? ($2) - виж това може да свърши работа.

#примерна постановка:
acl google dstdomain .google.com
cache deny google

като внимаваш на преден ред да нямаш cache allow all
т.е. реда на диретивите е важен във файла - обик. политиката е
cache allow ...
cache allow ...
cache deny all
или обратно
cache deny ...
cache deny ...
cache allow all

Не съм го пейстнал, просто в бързината така изглежда :) Промених го според нуждите ми.

Сега тествах доста работи и с cache deny и с aways_direct. В заключение се оказа, че проблема е следния:

GeSHi (Bash):
1451325816.724   5611 192.168.1.36 TCP_TUNNEL/200 892 CONNECT www.google-analytics.com:443 - HIER_DIRECT/216.58.208.110 -
1451325816.755     32 192.168.1.36 TCP_TUNNEL/200 580 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1451325816.759     32 192.168.1.36 TCP_TUNNEL/200 572 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
-->>1451325816.763      1 192.168.1.36 TCP_DENIED/403 370 CONNECT www.google.com:443 - HIER_NONE/- text/html<<--
1451325816.877    149 192.168.1.36 TCP_TUNNEL/200 1014 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1451325821.888   5164 192.168.1.36 TCP_TUNNEL/200 1232 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1451325821.891   5134 192.168.1.36 TCP_TUNNEL/200 585 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1451325821.903   5137 192.168.1.36 TCP_TUNNEL/200 561 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1451325821.912   5181 192.168.1.36 TCP_TUNNEL/200 1639 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
1451325821.940   5354 192.168.1.36 TCP_TUNNEL/200 5987 CONNECT my.rapido.bg:443 - HIER_DIRECT/94.155.49.90 -
 

Ако добавя google.com в white списъка , captch-ата се появява, но има и достъп до google, а аз искам да избегна този момент.