Respostas no Fórum
-
Posts
-
🚀 Apresentando o Hotspot Beacon! 🚀
Desbloqueie o potencial do seu Wi-Fi com o Hotspot Beacon. Personalize sua página de acesso para mostrar anúncios, promoções ou informações e engajar seus clientes, impulsionando o seu negócio.
💡 Principais Funcionalidades:
- Interface amigável e intuitiva
- Opções de personalização completas para sua marca
- Gerenciamento de propagandas e promoções
- Integração fácil com sistemas existentes via API
- Limitação de velocidade ou largura de banda por usuário
- Controle de acesso por horário
🔗 Confira o site para saber mais: https://hotspotbeacon.comEmanuel,
A porta 9999 pertence ao dansguardian, verifique nos logs deste se aparece alguma mensagem.
EDIT: Verificando o post http://endian.eth0.com.br/topic/proxy-lento-endian-24 acredito que você tenha instalado a nova versão…
luiztomaz,
Acredito que você esteja fazendo alguma confusão:
– System Access: Regras de acesso ao servidor do endian
– Port Forwarding / NAT – Regras de acesso a outros servidores.
(em firewall verifique a opção “Firewall Diagrams”)
Quanto a sua pergunta: Você pode sim liberar portas apenas para uma faixa de IPs. Ao criar a sua regra de liberação utilize o campo Source.
Mais informações aqui: http://endian.eth0.com.br/topic/redirecionamento-de-portas-no-endian-23
tnol2,
Dediquei um tempinho para revisar o seu firewall e não encontrei onde está a falha…
Pelos testes que você realizou, eu pude observar que o seu iptables está funcionando como deveria, mas a principio tem alguma regra em algum lugar da tabela filter que está liberando acesso total ou parcial entre as zonas.
Apesar de não ter encontrado nada sólido, eu fiquei com uma suspeita referente a sua chain PORTFWACCESS.
Algum ip do campo destination desta tabela estava envolvido no teste que você realizou mais cedo?
Pelo que eu observei, esta cadeia tem o potencial de liberar acesso entre as zonas dependendo das regras que você inserir. (De certa forma, isto está correto).
Faça o seguinte teste fora do horário de expediente: (cuidado, alguns serviços vão parar de funcionar)
logado via SSH digite:
# iptables -F PORTFWACCESS
Agora tente realizar novamente os testes de telnet entre as redes.
ps: A maneira mais fácil para você reaplicar as regras removidas no comando acima é reinicializando o endian ou reaplicando o firewall pela web interface. (você definitivamente deve fazer isto após o teste)
[]’s
Denis,
Entenda que o proxy transparente funciona “apenas” para http. Neste modo o https passa direto pelo firewall.
Se você desabilitar o acesso http no outgoing firewall, mas mantiver o proxy transparente ativo, as estações vão continuar navegando normalmente. Entretanto, se você colocar alguma estação no bypass list do proxy, esta não poderá navegar pois não terá permissão para http no outgoing firewall.
Você pode no entanto bloquear http e https no outgoing firewall e desativar o proxy transparente. (Configurando o proxy manualmente nas estações). Desta forma tanto o http como o https “passariam” pelo squid.
[]’s
Ao invés de utilizar a blacklist do content filter, crie uma access policy bloqueando o destino **
[]’s
luiz,
Este assunto já foi discutido aqui: http://endian.eth0.com.br/topic/alterar-os-itens-do-menu-do-shell-do-servidor-endian
De qualquer forma, por razões de segurança você deveria impedir o acesso físico ao endian e remover o teclado/monitor.
Com acesso físico, teclado e monitor, recarregar as configurações default é o menor dos seus problemas 😛
[]’s
Samuel,
Se o msn não estiver configurado para utilizar proxy, crie uma regra no outgoing firewall liberando a porta tcp 1863.
Já existem outros tópicos sobre o assunto no forum, utilize o campo pesquisar para mais informações
[]’s
tnol2,
Tem vários relatos de atualização aqui no forum, dê uma olhada ou utilize o campo pesquisar.
Devo lembrar que seria interessante resolver o seu problema do outro post antes de atualizar. A não ser que você vá instalar a 2.4 do zero.
[]’s
tnol2,
Utilize o pastebin para colar e forneça apenas os 3 links.
Se postar aqui o texto sai desalinhado, e fica dificil de compreender além de deixar o post quilométrico.
Entre em pastebin.com e “cole” o output lá.
[]’s
Bem, complementando:
Se não for só este problema, vamos debugar um pouco mais a sua rede:
Logue nos dois endians via SSH e digite
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.0.0/16 -p icmp -j ACCEPT (liberando ping e traceroute)
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.0.0/16 -p tcp –dport 3389 -j ACCEPT (liberando o TS para teste).
Testes nas redes:
A partir de uma máquina na rede A execute:
– ping para o IP do endian remoto
– ping para uma máquina da rede B
– traceroute para uma máquina da rede B
– Telnet para a porta 3389 de uma máquina da rede B (habilitar o terminal service/remote desktop da máquina em questão).
A partir de uma máquina na rede B execute:
– ping para o IP do endian remoto
– ping para uma máquina da rede A
– traceroute para uma máquina da rede A
– Telnet para a porta 3389 de uma máquina da rede A (habilitar o terminal service/remote desktop da máquina em questão).
* Lembre-se de desativar o firewall das máquinas envolvidas no teste (não o firewall do endian)
* Para remover as regras do iptables inseridas no teste, substitua o -I por -D
* Utilizar o tcpdump no endian (dos dois lados) pode ser MUITO, mas MUITO útil para encontrar o problema. Caso tenha dúvidas sobre como utilizar, escrevi umas dicas aqui: http://linux.eduardosilva.eti.br/canivete-suico-para-redes
* Se todos estes testes forem concluídos com sucesso, as suas rotas estão corretas e você só vai precisar ajustar o seu VPN firewall. Habilite-o e utilize regras apenas pela web interface.
denisfm,
Acredito que o manual da 2.4 ainda não saiu. Você pode acessar o material mais recente em:
Atualmente este é para a versão 2.3 mas deve servir para quebrar o galho, as duas versões são bem parecidas.
[]’s
Olá Roger,
Bem vindo a comunidade 🙂
Gostei da sua topologia em ASCII, facilitou bastante na visualização do ambiente.
Numa primeira olhada, eu pude observar que no seu endian A você não possui rota para a rede B. Esta pode ser a origem do problema.
Ajuste o problema das rotas e faça novos testes.
Notas:
– Direct all client traffic through the VPN server – No seu caso realmente não é uma boa idéia
– É recomendável utilizar firewall e permitir apenas os protocolos necessários. No firewall do endian existe uma parte reservada apenas para tráfego de VPN. (não é necessário nenhuma regra manual para isto).
– Pessoalmente eu também prefiro o OpenVPN ao invés do IPSec.
[]’s
tnol2,
Definitivamente tem algo de errado com o seu endian, o ideal seria revisar o seu iptables por completo e ver onde que o tráfego está sendo liberado.
Faça um dump completo do seu iptables para que eu possa analisar ele.
Logado via ssh no firewall digite:
iptables -t filter -L -nv
iptables -t nat -L -nv
iptables -t mangle -L -nv
Utilize o pastebin para colar os resultados de cada tabela. (um documento do pastebin para cada comando)
Não esqueça de “ocultar” os endereços públicos mantendo eles como únicos: exemplo
onde for 201.1.1.1 substitua por 201.1.X.X.
onde for 201.1.1.2 substitua por 201.1.X.Y
A tabela filter é a mais importante, provavelmente é lá que está a nossa resposta, mas por via das dúvidas, poste todas as outras.
[]’s
