sites https nao entram no squid 2.7 transparent

driovitor
(usa Kurumin)

Enviado em 04/04/2011 - 09:54h

Estou utilizando squid 2.7 transparente para as pessoas de onde trabalho acessarem a rede sem fio, nao tenho interesse de bloquear nada apenas liberar internet par ao povo.


Segue o meu squid.conf e firewall

firewall


#!/bin/bash
2
3 iptables -F
4 iptables -X
5 iptables -t nat -F
6 iptables -t nat -X
7 iptables -t mangle -F
8 iptables -t mangle -X
9 iptables -P INPUT ACCEPT
10 iptables -P FORWARD ACCEPT
11 iptables -P OUTPUT ACCEPT
12 iptables -A INPUT -i lo -j ACCEPT
13 iptables -A INPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
14 iptables -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
15
16
17 iptables -A FORWARD -i eth1 -p tcp --dport 443 -j ACCEPT
18
19
20
21 iptables -A INPUT -i eth1 -j ACCEPT
22
23
24
25
26
27 iptables -t nat -A POSTROUTING -s 192.168.100.0/255.255.255.0 -o eth0 -j MASQUERADE
28
29 iptables -t nat -A PREROUTING -s 192.168.100.0/255.255.255.0 -p tcp --dport 80 -j REDIRECT --to-port 3128
30




squid.conf


acl all src all
600 acl manager proto cache_object
601 acl localhost src 127.0.0.1/32
602 acl to_localhost dst 127.0.0.0/8
603 #
604 # Example rule allowing access from your local networks.
605 # Adapt to list your (internal) IP networks from where browsing
606 # should be allowed
607 #acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
608 acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
609 acl localnet src 192.168.100.0/24 # RFC1918 possible internal network
610 #
611 acl SSL_ports port 443 # https
612 acl SSL_ports port 563 # snews
613 acl SSL_ports port 873 # rsync
614 acl Safe_ports port 80 # http


acl Safe_ports port 21 # ftp
616 acl Safe_ports port 443 # https
617 acl Safe_ports port 70 # gopher
618 acl Safe_ports port 210 # wais
619 acl Safe_ports port 1025-65535 # unregistered ports
620 acl Safe_ports port 280 # http-mgmt
621 acl Safe_ports port 488 # gss-http
622 acl Safe_ports port 591 # filemaker
623 acl Safe_ports port 777 # multiling http
624 acl Safe_ports port 631 # cups
625 acl Safe_ports port 873 # rsync
626 acl Safe_ports port 901 # SWAT
627 acl purge method PURGE
628 acl CONNECT method CONNECT
629
630
631 acl permitidos dstdom_regex -i "/etc/squid/permitidos"
632


#Recommended minimum configuration:
655 #
656 # Only allow cachemgr access from localhost
657 http_access allow manager localhost
658 http_access deny manager
659 # Only allow purge requests from localhost
660 http_access allow purge localhost
661 http_access deny purge
662 # Deny requests to unknown ports
663 http_access deny !Safe_ports
664 # Deny CONNECT to other than SSL ports
665 http_access deny CONNECT !SSL_ports
666 #
667 # We strongly recommend the following be uncommented to protect innocent
668 # web applications running on the proxy server who think the only
669 # one who can access services on "localhost" is a local user
670 #http_access deny to_localhost
671 #
672 # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
673
674 # Example rule allowing access from your local networks.
675 # Adapt localnet in the ACL section to list your (internal) IP networks
676
677 # from where browsing should be allowed
678 http_access allow localnet
679 http_access allow localhost
680 http_access allow permitidos


#Allow ICP queries from local networks only
720 icp_access allow localnet
721 icp_access deny all

http_port 3128 transparent


access_log /var/log/squid/access.log squid


#Suggested default:
2740 refresh_pattern ^ftp: 1440 20% 10080
2741 refresh_pattern ^gopher: 1440 0% 1440
2742 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
2743 refresh_pattern (Release|Package(.gz)*)$ 0 20% 2880
2744 refresh_pattern . 0 20% 4320

Diede
(usa Debian)

Enviado em 04/04/2011 - 10:08h

Redirecionar HTTPS? Só uma coisa a dizer: É assim mesmo.
Sua regra de redirecionamento só especifica a porta 80, e HTTPS é porta 443. Porém, mesmo que você faça uma regra "iptables -t nat -A PREROUTING -s 192.168.100.0/255.255.255.0 -p tcp --dport 443 -j REDIRECT --to-port 3128", não irá funcionar, pois o conteúdo HTTPS é criptografado, o squid não pode manipulá-lo.
As duas únicas "pontas" que podem manusear o HTTP dentro de um pacote HTTPS é o browser e o server web, se não seria Man-in-the-middle-attack.

eduardo
(usa Linux Mint)

Enviado em 04/04/2011 - 10:17h

Resumindo, com proxy transparente, a única forma de fazer funcionar o HTTPS é marcando o proxy (o que tira a ideia de proxy transparente) ou liberando no firewall a porta 443 (o que não é recomendado).

Não recomendo liberar geral a 443 porque fazendo isso você abre uma brecha de segurança na sua rede. A situação menos preocupante que pode acontecer é que o pessoal pode descobrir e acessar a internet sem restrições através da porta 443, burlando o proxy.

driovitor
(usa Kurumin)

Enviado em 04/04/2011 - 10:40h

Eu usava o kurumin como servidor e estava funcionando como transparente sem problemas, agora que vim para o debian o serviço nao funciona mais, alias so funciona se eu colocar o proxy no navegar ae vai blz, porem se eu deixar dessa forma as pessoas iram encontram gtande dificuldade para estar acessando.

Diede
(usa Debian)

Enviado em 04/04/2011 - 10:49h

Ok, só por desencargo:
A navegação *HTTPS* não funciona sem setar o proxy, ou nem *HTTP* funciona sem proxy setado?!

driovitor
(usa Kurumin)

Enviado em 04/04/2011 - 10:55h

a navegação funciona normal sem o proxy no navegar, porem sites https, so funciona como proxy no navegar

Diede
(usa Debian)

Enviado em 04/04/2011 - 11:02h

Ok, teste rápido:
Em alguma máquina cliente, tente pingar algum site (ping www.google.com.br). Se não pingar, seu firewall está incorreto.
De qualquer forma, post aqui a saída do seu ifconfig (ifconfig -a)

eduardo
(usa Linux Mint)

Enviado em 04/04/2011 - 11:07h

Cara, se não pingar isso não significa que o firewall esteja incorreto. De qualquer forma, pingar um site não tem relação nenhuma com https.

Olha, não funcionar https com proxy transparente é perfeitamente normal. É um problema que todos enfrentamos. Nesses casos, a única forma de resolver, é liberando o a 443 para a máquina que necessita o https ou configurando o proxy. Infelizmente, é assim.

driovitor
(usa Kurumin)

Enviado em 04/04/2011 - 11:23h

Em uma maquina cliente tentei pingar varios sites e nenhuma pinga, so aparece o ip porem nao pinga, mas acesso a pagina, exceto as que partes https.,
segue saida ifconfig -a

eth0 Encapsulamento do Link: Ethernet Endereço de HW 00:10:4B:0F:F5:B3
inet end.: xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.xxx Masc:xxx.xxx.xxx.x
endereço inet6: fe80::210:4bff:fe0f:f5b3/64 Escopo:Link
UP BROADCASTRUNNING MULTICAST MTU:1500 Métrica:1
RX packets:22370 errors:0 dropped:0 overruns:0 frame:0
TX packets:17669 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:23853712 (22.7 MiB) TX bytes:2876089 (2.7 MiB)
IRQ:217 Endereço de E/S:0xac00

eth1 Encapsulamento do Link: Ethernet Endereço de HW 00:08:54:68:EF:CB
inet end.: 192.168.100.5 Bcast:192.168.100.255 Masc:255.255.255.0
endereço inet6: fe80::208:54ff:fe68:efcb/64 Escopo:Link
UP BROADCASTRUNNING MULTICAST MTU:1500 Métrica:1
RX packets:11813 errors:0 dropped:0 overruns:0 frame:0
TX packets:15546 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:1905155 (1.8 MiB) TX bytes:15702384 (14.9 MiB)
IRQ:169 Endereço de E/S:0xe800

lo Encapsulamento do Link: Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:61 errors:0 dropped:0 overruns:0 frame:0
TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:4917 (4.8 KiB) TX bytes:4917 (4.8 KiB)

sit0 Encapsulamento do Link: IPv6 sobre IPv4
NOARP MTU:1480 Métrica:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Diede
(usa Debian)

Enviado em 04/04/2011 - 11:23h

Thedrummer,
Sabemos que ICMP (ping) não tem relação com https, mas o foco não é esse. Não é um teste que relacione ping com https, é um teste de saída à web pelas máquinas da rede interna.
O masquerade do Firewall dele está ativo, e as regras estão como deveriam. Se não pingar, é porque as interfaces estão incorretas no firewall. Logo, firewall incorreto, concorda?!

Na verdade, não funcionar https no proxy transparente só é "normal" se o firewall não estiver corretamente configurado, e uma solução é como dito no seu próprio exemplo, liberar a porta 443. Claro, à parte com qualquer questão de segurança ou brecha de acesso (ultrasurfs, proxy externo https...)
Ou quem sabe fazer uso de WPAD...

driovitor
(usa Kurumin)

Enviado em 04/04/2011 - 11:28h

posso estar liberando a porta 443 no firewall dessa forma ou fiaria errado, nao manjo muito so apenas um curioso


#iptables -A FORWARD -s 192.168.100.0/24 -p tcp --destination-port 443 -j ACCEPT
#iptables -A OUTPUT -s 192.168.100.0/24 -p tcp --destination-port 443 -j ACCEPT

Diede
(usa Debian)

Enviado em 04/04/2011 - 11:33h

Seria no caso a primeira regra (FORWARD), mas ela não é necessária, pois na regra "iptables -A FORWARD -i eth1 -p tcp --dport 443 -j ACCEPT" você já tá fazendo a mesma permissão. Output é para o que vem da própria máquina, que no caso seria a máquina do Firewall.
A configuração das interfaces bate com o que tá no firewall.
Poste o conteúdo do seu "iptables-save" para sabermos se não há alguma outra regra além das que você postou lá em cima.