OLÁ, MEU SERVIDOR MK AUTH DEU PROBLEMA, FIZ A INSTALAÇÃO E BACKUP, DEPOIS DISSO NÃO AUTENTICA MAIS CLIENTES,ALGUÉM PODE ME AJUDAR..
Para adicionar comentários, você deve ser membro de MK-AUTH.
This reply was deleted.
OLÁ, MEU SERVIDOR MK AUTH DEU PROBLEMA, FIZ A INSTALAÇÃO E BACKUP, DEPOIS DISSO NÃO AUTENTICA MAIS CLIENTES,ALGUÉM PODE ME AJUDAR..
Para adicionar comentários, você deve ser membro de MK-AUTH.
Respostas
Estou com esse problema:
Eu estava usando a versão 24.05 Tux 4.9 há 2 anos, e funcionava perfeitamente. Porém, semana passada meu disco começou a encher durante o backup da madrugada e o Mkauth parava de autenticar os clientes por falta de espaço em disco. Os clientes que desconectavm o pppoe na madrugada ficavam desconectados. Então eu excluía o backup e voltavam a autenticar imediatamente.
Porém, dia de sábado, há 4 dias atrás, o disco encheu que nem fez o backup da madrugada e amanheceram desconectados. No sábado eu fiz uma nova instalação do Mkauth em um disco maior. Instalei a versão 24.xx Tux 6.6 e fiz upgrade que atualizou para a última disponível (25.03 Tux 6.6) e restaurei o backup. Todos os clientes autenticaram normalmente até ontem terça feira.
Porém, hoje amanheceu com os clientes desconectados. No log do Mikrotik, apareciam tentando autenticar via PPPoE com erro "user renilza authentication failed - radius timeout". Selecionei alguns clientes no Mkauth e mandei reparar, mas não voltaram. Então reiniciei o Mkauth, e todos voltaram.
Mas descobri algo: eles pararam de autenticar logo após o Mkauth ter feito o backup da madrugada. O backup finalizou às 02:27h e, um minuto depois, uma cliente desconectou e já não conseguiu mais se conectar.
A partir daí, todos os clientes que foram desconectando passaram a apresentar o mesmo erro no log, sem conseguir reconectar. Só voltaram após eu reiniciar o MKAuth à 06:40h.
Antes do horário em que o Mkauth fez o backup, todos os PPPoEs que desconectavam reconectavam normalmente logo em seguida. Ou seja, o problema começou após a execução do backup.
O HD atual está com 70 GB livres, então não é mais falta de espaço.
As configurações entre Mikrotik e MKAuth estão corretas e passaram no teste da regra de SSH — tanto que os clientes reconectaram normalmente durante os 3 dias após a instalação.
O problema agora é a insegurança de não saber em qual dia os clientes podem amanhecer desconectados novamente.
No Netwatch do Mikrotik, tenho um ping que me envia e-mail caso o kauth pare de responder, mas ele não parou de pingar — ou seja, o servidor estava ativo, mas o serviço de autenticação aparentemente travou após o backup.
Lembrei que ontem eu executei esse comando no putty pois queria saber se conseguia um script que fizesse bachup completo /opt/mk-auth/hhvm/5-3-16/bin/php /opt/mk-auth/scripts/backup.php 2> /dev/null
Esse script pode ter causado isso?
erros de conexão sempre é falha do radius, abaixo possiveis erro com algumas soluções:
Porta do accounting no MikroTik não é a padrão 1813 e a authenticate não é 1812:
troque as portas para o padrão correto, ou seja 1812 e 1813.
Falha de comunicação do mk-auth com seu MikroTik:
com um ping de um para o outro vc observa por alguns instantes se responde corretamente, se não reveja sua rede.
Para testar a comunicação ssh agora o sistema envia uma regra desabilitada para o filter do MikroTik, se gravar a regra é pq esta ok...
IP que o cliente usa no momento não é o mesmo ip gravado no sistema:
veja o tempo de validade que vc colocou em seu dhcp-server que se foi menor do que 3 dias aumenta para 3 dias.
Pode-se configurar o cliente tool fetch do MikroTik para controlar o DHCP, pois é a melhor forma agora para enviar os ips do DHCP ao MikroTik.
Usando o script do link abaixo, primeiro faça um update do sistema, então é preciso que seus clientes tenham o IP e MAC definidos no cadastro deles. esse script do link vc cola no terminal do MikroTik, no codigo dele vc altera se for preciso ip do mk-auth 172.31.255.2 e a altera key_api que vc pega na pagina de dados do provedor no webadmin.
www.mk-auth.com.br/tool_fetch/dhcp.txt
O script é todo automatico, ele coloca e remove os ips do DHCP sozinho a cada 45 minutos.
Tempo do interim update no MikroTik maior do que 3 minutos podem fazer o sistema desconectar clientes:
configure o tempo de interim como 00:05:00 e teste novamente.
Senha errada, as vezes o navegador troca a senha do cliente ao alterar algum dado do mesmo no webadmin:
teste com outro navegador e em opções coloque o item case sensitive como não e teste novamente.
Tipo de conexão errado (hotspot e pppoe) no cadastro do cliente no webadmin:
configure o tipo de conexão correto no cadastro do cliente.
MAC que o cliente usa esta errado, não é o mesmo gravado no sistema:
remova o mac que estiver salvo no cadastro do cliente e teste novamente.
Ramal que esta definido para o cliente não é o correto ou o ramal esta com ip errado:
coloque o ramal todos no cadastro do cliente e nas configurações de radius do MikroTik coloque o secret 123456.
MikroTik não esta cadastrado no MK-AUTH, ou ip secrect estão errados no webadmin:
faça um update do mk-auth e coloque no MikroTik nas configurações de radius o secret 123456 e no cliente o ramal todos.
Marcar a opção night sem querer no cadastro do cliente, assim o sistema irar desativar o mesmo alguma hora:
desmarque o item night no cadastro do cliente.
Dados do cliente mal formatados no banco do servidor radius:
selecione o cliente e clique no icone reparar ou então use o comando mk-auth e escolha reparar clientes.