Configurar rede MK-Auth instalado no Hyper-V

Olá a todos.

Estou instalando o Mk-Auth e tenho problema na config. da rede.

O servidor tem uma placa de rede para o Mk-Auth, (separada da placa do servidor) criei uma "virtual Switch " no hyper-v, exclusiva para o Mk-Auth, colocado o ip nela 192.168.111.228 (ip fixo.

Feito a instalação do Mk-Auth no hyper-v, configurado o ip 192.168.111.229(Mk-Auth).

Na instalação do Mk-Auth ele não reconhece a placa do hyper-v, tem como fazer ele reconhecer a placa rede do hyper-v?

Se alguém puder me ajudar, agradeço.

Para adicionar comentários, você deve ser membro de MK-AUTH.

Join MK-AUTH

Votos 0
Enviar-me um email quando as pessoas responderem –

Respostas

  • Olá, Sim, esta 100%, não tive nenhum problema. Obs: O Mk-Auth não restaurei base de dados, configurei tudo do inicio.

    Tec Info Wi-Fi disse:

    Olá, Flavio Silva. Seu Mk auth está rodando 100% no Hyper-v server 2016? Pois tenho um Dell PowerEdge e gostaria de virtualizar a maquina com Mk auth + Mikrotik CHR + Elastix + DNS. Nas minhas pesquisas gostei muito do Hyper-v Mas ainda não instalei nenhum Hypervisor na minha maquina.

    Flavio Silva disse:

    Obrigado a todos por compartilhar suas experiência, consegui resolver meu problema, colocando as interfaces de rede do servidor em modo bridge, Mk-Auth esta em produção, funcionando 100%.

  • Olá, Flavio Silva. Seu Mk auth está rodando 100% no Hyper-v server 2016? Pois tenho um Dell PowerEdge e gostaria de virtualizar a maquina com Mk auth + Mikrotik CHR + Elastix + DNS. Nas minhas pesquisas gostei muito do Hyper-v Mas ainda não instalei nenhum Hypervisor na minha maquina.

    Flavio Silva disse:

    Obrigado a todos por compartilhar suas experiência, consegui resolver meu problema, colocando as interfaces de rede do servidor em modo bridge, Mk-Auth esta em produção, funcionando 100%.

  • Obrigado a todos por compartilhar suas experiência, consegui resolver meu problema, colocando as interfaces de rede do servidor em modo bridge, Mk-Auth esta em produção, funcionando 100%.

  • Como alternativa ao VMWare, migrar para o Hyper-V é uma regressão.

    DAVID STOCCO JUNIOR disse:

    eu virtualizo pelo hiperV. se quiser uma ajuda me adiciona 41998555452 daivid

  • eu virtualizo pelo hiperV. se quiser uma ajuda me adiciona 41998555452 daivid

  • O seu problema é desempenho inferior de rede e I/O do Hyper-V.

    O MK-AUTH precisa responder rapidamente às requisições, dentro do parâmetro "timeout" do RADIUS no Mikrotik.
    Como você bem observou, a resposta do ambiente Hyper-V, tanto em rede quanto I/O, é inferior ao VMWare.

    Pablo Z Silva disse:

    Prezados,

    Ontem resolvi ativar o novo servidor utilizando Vmware ESXI provisóriamente até conseguir solucinar os problemas do Hyper-V. Em testes verifiquei que o a VM do Mkauth no ESXI do servidor novo apresenta os mesmos logs de erro e aviso Freeradius repetitivos que eram apresentados quando estava rodando em Hyper-V. O que a VM do Servidor ESXI que está em produção não faz.

    As únicas diferenças entre a VM no servidor novo com Hyper-v e com ESXI é que no ESXI a autenticação Radius Wireless apresenta o mesmo log (vide abaixo), porem conecta o cliente instantaneamente, e a reparação de clientes demora 3x menos.

    Auth: Login OK: [6C:3B:6B:D1:60:DB] (from client SVM-SD4 port 0 cli 6C-3B-6B-D1-60-DB)
    Info: No Pool-Name defined (did D4-CA-6D-E2-09-D1:ClickSVM-SD4 cli 6C-3B-6B-D1-60-DB port user 6C:3B:6B:D1:60:DB)

    Isso me levou a questionar 2 fatores:

    1-)Esses logs repetitivos se referem a alguma informação registrada no Concentrador PPPoE pelo servidor em produção que não bate com o que está no servidor novo na hora da virada? Pois estou virando de um sistema pro outro a quente, simplesmente desabilitando uma interface e habilitando outra. O que mantem os cliente autenticados pelo servidor que estava em produção conectados. Já para o servidor novo eles estariam desconectados, já que ele acabou de entrar na rede.

    2-)Algum problema relacionado ao sistema de arquivos de uma máquina pra outra, já que o servidor de produção está com 1 SSD e o novo com 2 em Raid1?

    O que me intrigou é que a mesma VM, em servidores quase identicos, apresenta comportamentos de log diferentes.

    Se alguem tiver uma idéia para compartilhar, será muito bem vinda.

    Um abraço a todos !

  • Prezados,

    Ontem resolvi ativar o novo servidor utilizando Vmware ESXI provisóriamente até conseguir solucinar os problemas do Hyper-V. Em testes verifiquei que o a VM do Mkauth no ESXI do servidor novo apresenta os mesmos logs de erro e aviso Freeradius repetitivos que eram apresentados quando estava rodando em Hyper-V. O que a VM do Servidor ESXI que está em produção não faz.

    As únicas diferenças entre a VM no servidor novo com Hyper-v e com ESXI é que no ESXI a autenticação Radius Wireless apresenta o mesmo log (vide abaixo), porem conecta o cliente instantaneamente, e a reparação de clientes demora 3x menos.

    Auth: Login OK: [6C:3B:6B:D1:60:DB] (from client SVM-SD4 port 0 cli 6C-3B-6B-D1-60-DB)
    Info: No Pool-Name defined (did D4-CA-6D-E2-09-D1:ClickSVM-SD4 cli 6C-3B-6B-D1-60-DB port user 6C:3B:6B:D1:60:DB)

    Isso me levou a questionar 2 fatores:

    1-)Esses logs repetitivos se referem a alguma informação registrada no Concentrador PPPoE pelo servidor em produção que não bate com o que está no servidor novo na hora da virada? Pois estou virando de um sistema pro outro a quente, simplesmente desabilitando uma interface e habilitando outra. O que mantem os cliente autenticados pelo servidor que estava em produção conectados. Já para o servidor novo eles estariam desconectados, já que ele acabou de entrar na rede.

    2-)Algum problema relacionado ao sistema de arquivos de uma máquina pra outra, já que o servidor de produção está com 1 SSD e o novo com 2 em Raid1?

    O que me intrigou é que a mesma VM, em servidores quase identicos, apresenta comportamentos de log diferentes.

    Se alguem tiver uma idéia para compartilhar, será muito bem vinda.

    Um abraço a todos !

  • Caro Pedro, Patrícia e demais,

    Venho aqui solicitar ajuda a respeito do funcionamento do MkAuth 4.113 64bits Jessie/Debian 8.1 junto ao Virtualizador Hyper V Server 2016. Havia desistido de efetuar a migração, porem como qualquer pessoa da área computacional, não me dou por satisfeito com explicações sem comprovação. Como em ambas as documentações, tanto do Hyper-V quanto do Debian não apresentam nada que desqualifique o trabalho em conjunto, a incompatibilidade não foi uma explicação que me satisfez. Analisando + a fundo o que ocorre é o seguinte:

    Sempre trabalhei com Vmware ESXI 6.5 e ultimamente o 6.7 freeware, porem essas soluções já não atendem minhas necessidades pela escassez de recursos. Resolvi experimentar o Hyper-V.

    Todas as outras 6 VMs, incluindo Ubuntu 14.04, 16.04.6, 18.04.2, Windows 2008 e 2012 como guests estão rodando perfeitamente. Quando efetuo a migração do MK-Auth na versão supracitada, começo a ter problemas, especificamente com o FreeRadius.

    Abaixo alguns logs que não aparecem no VMware que inundam o log do radius com Hyper-V:

    Info: WARNING: Child is hung for request 741 in component <core> module (Varias vezes por minuto só mudando o numero do request)

    Error: Discarding conflicting packet from client Autenticador port 37634 - ID: 41 due to recent request 934. (Varias vezes por minuto só mudando a porta e o request)

    Info: WARNING: Module rlm_sql became unblocked for request 952 (Varias vezes por minuto só mudando o request)

    Em breve pesquisa me parece que essas informações se referem a banco de dados corrompido. O que não é a minha realidade.

    Outro problema que percebi foi em relação as autenticações Radius Wireless, onde o MAC tem que estar cadastrado e ativo no MK-Auth para o AP aceitar a conexão na torre. Todos os clientes Wireless que dependem dessa autenticação distribuída só conseguem se conectar depois de uns 10 minutos de tentativas do equipamento. No log do AP fica só apresenta reconnecting repetidas vezes. Nesse caso o log do radius fica se repetindo:

    Auth: Login OK: [6C:3B:6B:D1:60:DB] (from client SVM-SD4 port 0 cli 6C-3B-6B-D1-60-DB)
    Info: No Pool-Name defined (did D4-CA-6D-E2-09-D1:ClickSVM-SD4 cli 6C-3B-6B-D1-60-DB port user 6C:3B:6B:D1:60:DB)
    Auth: Login OK: [6C:3B:6B:D1:60:DB] (from client SVM-SD4 port 0 cli 6C-3B-6B-D1-60-DB)
    Info: No Pool-Name defined (did D4-CA-6D-E2-09-D1:ClickSVM-SD4 cli 6C-3B-6B-D1-60-DB port user 6C:3B:6B:D1:60:DB)

    Assim que desativo o servidor MK-Auth em Hyper-V e ativo o servidor em VMware tudo volta ao normal.

    Já os clientes de fibra que não dependem da autenticação wireless nos APs se conectam normalmente. E mesmo os cliente que já estão conectados via wireless se conectam no Concetrador sem nenhum problema. Só a autenticação wireless é afetada.

    O que eu já tentei:

    O Hyperv-daemon referente a versão do Debian está instalado e ativo (Integração entre Servidor e VM)

    Reparar os Dados.

    Reparar os Clientes.

    Reparar o mysql.

    Efetuar uma instalação limpa com a ultima ISO diretamente no Hyper-V eliminando importação de VM do Vmware e voltando o backup.

    Aparentemente o restante do MKauth está funcionando perfeitamente, incluindo apache2 e mysql pois em momento algum as tabelas são corrompidas ou algum erro é apresentado nos logs em questão.

    Hardware Utilizado: Dell PowerEdge 610 com 2 Xeon + 2 SSDS de 1 TB em Raid1 e 64 GB de memoria, sendo 80GB/8GB o disco e a memória reservados para o MKAuth respectivamente.

    Gostaria de obter um auxilio/sugestão a respeito de como proceder para tentar mitigar a questão ou até mesmo uma documentação oficial que diga que os sistemas não conseguem trabalhar juntos adequadamente. Pois já li sobre casos onde estão usando Mkauth em Hyper-V Server com sucesso.

    Sem mais, como sempre agradeço a atenção que sempre me é prestada....

    Um abraço a todos !!!

  • Não há razão técnica a favor do Hyper-V para guests GNU/Linux,, como o MK-AUTH.

    VMWare e Proxmox são as melhores opções.

    Pablo Z Silva disse:

    Tive problemas de compatibilidade ao tentar efetuar a migração de virtualizadores (Vmware Esxi 6.7 para Hyper-V Server 2016). De todas as 7 VMs virtualizadas tive que desistir por conta do Mkauth (Debian Jessie) pois ao colocar em produção apresentou lentidão e falha na base de dados. Mesmo uma instalação Nova do MKauth com a ultima ISO não solucionou. As interfaces de rede são reconhecidas normalmente, porem não há integração entre VM e Virtualizador mesmo com a instalação do hyperv-daemon apropriado e começa a presentar atrasos no acesso HTTP e autenticação Radius até que o banco de dados fica indisponível depois de algum tempo. Alguns tipos de autenticação Radius nem funcionam direito. Todo log de inicialização aparece com correção da partição SDAx. Perdi uma semana com isso para ao final deixar pra lá por falta de tempo. O reconhecimento de interfaces e drivers vai ser o menor dos seus problemas. Já que pelo menos pra mim, o Mkauth é uma aplicação crítica e não pode haver dúvidas quanto o seu correto funcionamento.

  • Tive problemas de compatibilidade ao tentar efetuar a migração de virtualizadores (Vmware Esxi 6.7 para Hyper-V Server 2016). De todas as 7 VMs virtualizadas tive que desistir por conta do Mkauth (Debian Jessie) pois ao colocar em produção apresentou lentidão e falha na base de dados. Mesmo uma instalação Nova do MKauth com a ultima ISO não solucionou. As interfaces de rede são reconhecidas normalmente, porem não há integração entre VM e Virtualizador mesmo com a instalação do hyperv-daemon apropriado e começa a presentar atrasos no acesso HTTP e autenticação Radius até que o banco de dados fica indisponível depois de algum tempo. Alguns tipos de autenticação Radius nem funcionam direito. Todo log de inicialização aparece com correção da partição SDAx. Perdi uma semana com isso para ao final deixar pra lá por falta de tempo. O reconhecimento de interfaces e drivers vai ser o menor dos seus problemas. Já que pelo menos pra mim, o Mkauth é uma aplicação crítica e não pode haver dúvidas quanto o seu correto funcionamento.

This reply was deleted.