no console do ubnt, via ssh !!
iptables -t filter -L -nv
Versão Imprimível
no console do ubnt, via ssh !!
iptables -t filter -L -nv
Pessoal, recentemente eu usei aqui o discovery tool da ubnt aqui na minha rede e achei alguns nanostations instalados em alguns clientes. A questão é, esses clientes tão conectados em painéis com rádios Ubiquiti, com essas regras de dropagem de tudo que não for pacote ppp. Creio que esses clientes não deveriam estar aparecendo no discovery, não entendo pq aparecem... Pensei que eles podiam estar enviando dados dentro dos pacotes ppp, mas eu rodei o discovery sem estar conectado no ppp, e acha esses clientes do mesmo jeito. Aparentemente apenas um dos meus aps está deixando vazar esses negócios, mas ele tá com as mesmas regras que os outros:
tem alguma merda aí?Citação:
aaa.1.status=disabled
aaa.status=disabled
bridge.1.devname=br0
bridge.1.fd=1
bridge.1.port.1.devname=eth0
bridge.1.port.1.status=enabled
bridge.1.port.2.devname=ath0
bridge.1.port.2.status=enabled
bridge.1.stp.status=disabled
bridge.status=enabled
dhcpc.1.devname=br0
dhcpc.1.status=disabled
dhcpc.status=disabled
dhcpd.1.status=disabled
dhcpd.status=disabled
dnsmasq.1.devname=eth0
dnsmasq.1.status=enabled
dnsmasq.status=disabled
ebtables.1.cmd=-t nat -A PREROUTING --in-interface ath0 -j arpnat --arpnat-target ACCEPT
ebtables.1.status=disabled
ebtables.2.cmd=-t nat -A POSTROUTING --out-interface ath0 -j arpnat --arpnat-target ACCEPT
ebtables.2.status=disabled
ebtables.3.cmd=-t broute -A BROUTING --protocol 0x888e --in-interface ath0 -j DROP
ebtables.3.status=disabled
ebtables.4.cmd=-A FORWARD -p 0x8863 -j ACCEPT
ebtables.4.status=enabled
ebtables.5.cmd=-A FORWARD -p 0x8864 -j ACCEPT
ebtables.5.status=enabled
ebtables.50.status=disabled
ebtables.51.status=disabled
ebtables.52.status=disabled
ebtables.6.cmd=-P FORWARD DROP
ebtables.6.status=enabled
ebtables.status=enabled
httpd.port=80
httpd.status=enabled
igmpproxy.status=disabled
iptables.3.status=disabled
iptables.status=disabled
Isso aqui eu uso nos APS, a regra liberando sua rede é para ter acesso aos rádios via IP e com as regras abaixo eu não consigo descobrir os rádios pelo discovery:
echo "ebtables -A FORWARD -p 0x8863 -j ACCEPT" > /etc/persistent/rc.poststart
echo "ebtables -A FORWARD -p 0x8864 -j ACCEPT" >> /etc/persistent/rc.poststart
echo "ebtables -A FORWARD -p IPv4 --ip-src sua_rede_gerencia --ip-dst sua_rede_gerencia -j ACCEPT" >> /etc/persistent/rc.poststart
echo "ebtables -A FORWARD -p ARP -j ACCEPT" >> /etc/persistent/rc.poststart
echo "ebtables -P FORWARD DROP" >> /etc/persistent/rc.poststart
cfgmtd -w -p /etc/
reboot
Agora o radio cliente vai conseguir com o discovery ver só o seu AP, senão quiser nem isso é só desabilitar o discovery nele, ou ver qual a porta/protocolo ele usa e dar um drop na chain input.
Att,
Anderson Araújo
valeu, vou tentar.
Na
o que tá em negrito é o que eu substituo pelo ip ou tem mais alguma coisa; esses -- antes de ip, são isso mesmo? E o ip, padrão xxx.xxx.xxx.xxx/xx ?Citação:
echo "ebtables -A FORWARD -p IPv4 --ip-src sua_rede_gerencia --ip-dst sua_rede_gerencia -j ACCEPT" >> /etc/persistent/rc.poststart
Mais uma: tem alguma razão especial pra se ter que colocar o ip de origem e o de destino? Nesse caso, é uma regra dessas pra cada station que tiver conectada no ap? Pq se for uma regra só pra uma rede inteira, acho que nao precisava ter src e dst, seria só o endereço da rede em que o ap e os stations estariam. Né não?
Acho que vou acabar não usando essa regra, não tenho conhecimento suficiente pra entender, e consigo acessar os stations pelos ips que eles pegam do servidor pppoe quando discam.