Squid ou Firewalld bloqueando acesso à Área de Trabalho remota

johwsm
(usa Ubuntu)

Enviado em 10/03/2023 - 12:41h

Olá, bom dia!
Vou explicar o que está acontecendo, e espero que alguém consiga me ajudar a resolver a questão.
Eu montei um Servidor Centos7 que fica na borda da internet com IP público. Nele tenho habilitado Selinux, Firewalld, Squid e SquiGuard.

Tenho duas interfaces ativas, uma para minha rede interna (zona internal) e outra na rede externa (zona external). Esse servidor serve internet para toda minha rede interna e atualmente são 110 computadores.
A navegação (protocolo HTTP e HTTPS) está funcionando muito bem, com os bloqueios e registros do SquidGuard todos certinhos.

external (active)

  target: default

  icmp-block-inversion: no

  interfaces: enp3s0

  sources:

  services: ssh

  ports: 3001/tcp 3128/tcp 7070/tcp 8090/tcp 554/tcp 3389/tcp

  protocols:

  masquerade: no

  forward-ports: port=8090:proto=tcp:toport=8090:toaddr=192.168.1.250

        port=3001:proto=tcp:toport=80:toaddr=192.168.1.242

        port=2096:proto=tcp:toport=3389:toaddr=192.168.1.178

        port=9923:proto=tcp:toport=9922:toaddr=192.168.1.242

  source-ports:

  icmp-blocks:

  rich rules:



internal (active)

  target: default

  icmp-block-inversion: no

  interfaces: enp4s0

  sources:

  services: dhcpv6-client mdns samba samba-client ssh

  ports: 3128/tcp 80/tcp 3001/tcp 7070/tcp 8090/tcp 3268/tcp 3389/tcp 554/tcp

  protocols:

  masquerade: yes

  forward-ports:

  source-ports:

  icmp-blocks:

  rich rules:

 

O problema está nos outros protocolos, mais especificamente nas conexões para Área de Trabalho externa, porta 3389, e protocolo MMS, porta 554. Alguns computadores da minha rede precisam acessar um outro servidor externo pela Área de Trabalho remota, e simplesmente não funciona. Já liberei a porta no firewalld e no squid, mas o problema persiste. O detalhe é que nem nos logs tem alguma pista do que pode estar acontecendo.

Na minha placa externa eu tenho o masquerade = no, pois eu preciso que o usuário utilize obrigatoriamente o proxy, configurando ele manualmente no navegador. Se eu deixar o masquerade da placa externa = yes, eu consigo usar qualquer protocolo e não tenho mais problema nenhum, no entanto, qualquer computador consegue utilizar a internet sem passar pelo Squid, ou seja, essa não é uma opção.

Na minha placa interna eu tenho o masquerade = yes, pois tenho alguns serviços internos com acesso público e para isso eu preciso fazer forward-ports.

Outro detalhe é que a conexão para Área de Trabalho remota dentro da minha rede interna funciona sem problema algum, assim, eu estou entendendo que o problema está justamente nesse mascaramento da placa interna para a externa e o Squid não está fazendo, a não ser para protocolo HTTP e HTTPS.

Com certeza eu deixei passar alguma coisa durante as instalações e configurações desses serviços, mas não consigo achar.

Vou colocar aqui meu squid.conf

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp

auth_param ntlm children 30

auth_param ntlm keep_alive on



auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic

auth_param basic children 5

auth_param basic realm Autenticacao de Usuario

auth_param basic credentialsttl 2 hours



authenticate_cache_garbage_interval 1 hour

authenticate_ttl 1 hour



###ACL PARA AUTCAO DO SQUID NO AD

acl autorizados proxy_auth REQUIRED



acl SSL_ports port 3389         

acl SSL_ports port 554          



acl Safe_ports port 3389      

acl Safe_ports port 554        



acl purge method PURGE

acl CONNECT method CONNECT



acl dominio_mydomain dstdomain .meudominio.com.br



delay_pools 2

delay_class 1 2

delay_class 2 2



delay_parameters 1 12500000/12500000 1250000/1250000

delay_parameters 2 -1/-1 -1/-1



delay_access 2 allow dominio_mydomain

delay_access 1 allow autorizados

delay_access 1 deny all



http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports



http_access allow localhost manager

http_access deny manager



http_access allow purge localhost

http_access deny purge



http_access deny to_localhost

http_access allow autorizados

http_access deny all



http_port 3128



cache_dir ufs /var/spool/squid 10000 16 256

coredump_dir /var/spool/squid



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



maximum_object_size 4096 KB

maximum_object_size 4096 KB

minimum_object_size 0 KB

maximum_object_size_in_memory 512 KB

cache_mem 256 MB

pipeline_prefetch on

fqdncache_size 1024

logfile_rotate 30

cache_swap_low 90

cache_swap_high 95

dns_nameservers 192.168.1.251 8.8.8.8 8.8.4.4

dns_v4_first on



hosts_file /etc/hosts

url_rewrite_program /usr/bin/squidGuard

 

Alguém tem alguma ideia do que está acontecendo nesse cenário? O que eu preciso fazer para que qualquer serviço do computador cliente funcione acessando a internet pelo Squid?

alexabolada
(usa Debian)

Enviado em 10/03/2023 - 12:41h

{
"error": {
"message": "This model's maximum context length is 4097 tokens, however you requested 4331 tokens (3381 in your prompt; 950 for the completion). Please reduce your prompt; or completion length.",
"type": "invalid_request_error",
"param": null,
"code": null
}
}

Buckminster
(usa Debian)

Enviado em 10/03/2023 - 13:49h

Acredito que o problema é no FirewallD.
Em forward-ports: na zona interna acrescente regras para a porta 3389 com os IPs desejados e teste.
Mais ou menos assim:
--add-forward-port=port=3389:proto=tcp:toport=2096:toaddr=ip_servidor_externo

Para ver as portas:
netstat -tulpn
ou
ss -tulpn

Para monitorar em tempo real:
sudo watch netstat -tulpn
ou
sudo watch ss -tulpn


Com o comando
ss -anp | grep 3389
ou
netstat -anp | grep 3389
tu descobre se a porta está aberta, fechada, escutando (listen), etc.

Com
lsof -i | grep 3389
tu obtém mais informações, caso retornar nada é porque a porta não está escutando.

https://www.vivaolinux.com.br/topico/Squid-Iptables/Liberar-porta-3389-acesso-remoto-TS

https://www.gnulinuxbrasil.com.br/?p=5186


________________________________________________
Always listen the Buck!

johwsm
(usa Ubuntu)

Enviado em 13/03/2023 - 09:08h

Olá Buckminster, obrigado pela resposta!

Demorei para te responder devido ao fluxo de trabalho aqui..

Vou tentar fazer o monitoramento com os comandos citados por você, mas a questão de fazer forward-ports na placa interna não é a intenção, pois o problema não está em alguém acessar de fora da minha rede algum serviço interno meu, mas sim em eu conseguir, de dentro da minha rede interna, acessar qualquer computador externo na Área de Trabalho.

Por exemplo: eu tenho um outro servidor Windows Server fora da minha rede, com outro IP público, e preciso acessar ele daqui onde estou. Ao tentar fazer a conexão via Área de Trabalho a conexão simplesmente não acontece e até agora não recebo nenhum log que me ajude a entender o que pode estar acontecendo. Lembrando que o meu computador está com o proxy (Squid) ativado nas configurações de rede. A única forma que encontrei de fazer isso funcionar é tirando as configurações do squid do meu computador e criar uma mascaramento para ele acessar a internet. Mas não posso fazer isso para todos os computadores que precisam acessar serviços externos, pois todos precisam passar pelo Squid.

Buckminster
(usa Debian)

Enviado em 13/03/2023 - 11:18h

Uma sugestão é fazer uma ACL no Squid liberando os IPs dos servidores/computadores que você quer acessar, mas para isso tu terá que fixar os IPs das máquinas externas e não sei se é conveniente ou se tu pode fazer isso.
Esse IP do servidor externo é público, mas é dinâmico ou estático?

Outra sugestão será tu criar VPN para esses acessos externos.

Tem uma maneira de fazer pelo MAC, mas daí envolve configuração do Squid e do Firewalld e não sei se será conveniente para ti, pois envolve também configurações no modem/roteador das máquinas externas que tu quer acessar.

Porém, vendo com mais atenção teu script do Squid, tente colocar as ACLs de liberação das portas antes da regra da autenticação e no firewalld mantenha as liberações/bloqueios para os determinados IPs:

acl SSL_ports port 3389
acl SSL_ports port 554

acl Safe_ports port 3389
acl Safe_ports port 554

###ACL PARA AUTCAO DO SQUID NO AD
acl autorizados proxy_auth REQUIRED

Reinicie o Squid e teste.

Veja no link abaixo a ordem de colocação das regras:
https://tidahora.com.br/servidor-proxy-squid-no-linux-centos-7-com-autenticacao-local/

Lembrando que é aconselhável colocar primeiro todas as liberações e depois os bloqueios.

Caso queira se aprofundar um pouco mais, no link abaixo tem regras básicas para se colocar:
https://www.vivaolinux.com.br/artigo/Squid-Entendendo-um-pouco-as-configuracoes/?pagina=4

E teu Squid, pelo que vejo está muuuito obsoleto, é a versão 2.5. O Squid está na versão 7.
Veja, a versão 2.5 nem é mais citada:
http://www.squid-cache.org/Doc/config/

Aqui outras indicações com exemplos oficiais:
http://wiki.squid-cache.org/ConfigExamples/Authenticate/Bypass">http://wiki.squid-cache.org/ConfigExamples/Authenticate/Bypass
http://wiki.squid-cache.org/ConfigExamples/


________________________________________________
Always listen the Buck!