[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: por default - todas interfaces de rede sao SEMPRE ethX?



Lucas Mocellin escreveu:
Olá pessoal,
estou desenvolvendo uma aplicação para o ensino a distância que faz uma conexão com um servidor remoto para realizar uma prova online através de uma VPN. Problema: Preciso fazer um botão "testar conexão" antes do usuário autenticar, então estou vendo se já existe algo pronto. Eu preciso testar a porta 443(SSL) e a porta 1194(OpenVPN) de um servidor remoto, principalmente para saber se há algum tipo de filtro (firewall) no meio. Até desenvolvi algo simples que testa a 443 TCP, porém não consegui testar a 1194 UDP, poise segundo o protocolo, se enviar uma conexão e ela "não responder" significa que está aberta ou filtrada (o teste do NMAP também segue esta lógica), caso esteja fechada retorna um REJECT. Porém esse teste não me serve, então penso que a única alternativa é simular um início de VPN segundo o protocolo do OpenVPN, o que ainda não faço a mínima idéia de como fazer. Primeiro: alguém conhece algum script/programa pronto que faz esse teste de conexão no estilo do Windows Live, abre uma janelinha "bonitinha" que mostra todos os testes e vai fazendo um "OK" nos passos que "passaram no teste", e que faça teste em conexões TCP e UDP? Essa seria a melhor alternativa, utilizar algo pronto.
- existe placa de rede no computador
- cabo está conectado (como no comando mii-tool)
- pegou IP de DHCP
- conexao com gateway
- resolucao de DNS
- se o IP que ele pegou não bate com o da VPN
- se há conexão na porta 443 TCP SSL do IP X
- se há conexão na porta 1194 UDP OpenVPN do IP Y
Toda sugestão é bem-vinda.
Obrigado e abraços,


Olá,

Em relação a testar as portas, se não tiver resposta, pode ser que o pacote se perdeu e está sendo consumido, então não dá para dizer se está aberta, fechada ou filtrada, pressupõe-se filtrada de conhece o programa no outro lado que está ouvindo na porta e esteja requisitando uma resposta dele e você tem a certeza que ele vai responder. Se não conhece o programa, apenas se receber um REJECT para afirma que está fechada, caso contrário pode estar aberta ou filtrada.

Quanto a ter relações estreitas com o hardware, somente com chamadas ao kernel ou chamadas a programas ou bibliotecas específicas. Neste caso, seria mais sensato "pingar" um servidor público por IP, tipo o ip do registro.br ou o ip do seu servidor mesmo. Feito isso, "pingar" este servidor por nome. Passado por estes dois testes, dá para ter certeza que tem placa de rede, que "o cabo" está conectado (e se for sem fio?), que tem conexão com um gateway, que o DNS está configurado e resolvendo nomes e de lambuja que tem acesso à Internet também.

Para saber se tem algum IP (acho que você que dizer classe) que bate com o reservado da VPN, melhor usar o resultado do comando "/sbin/route -n", pois aí tem o número das redes e sua máscara, então "calcula" se os IPs (ou classe) da VPN estão dentro dessas já configuradas nas diversas interfaces que o computador pode ter.

A partir daí é realizar a conexão teste VPN (como vai fazer isso?) e então dá para saber se a porta da VPN esta funcionando, se o servidor VPN está funcionando e se tem acesso a este servidor. O mesmo vale para a porta 443, se for https, faz um GET e espera pela resposta.

Não conheço o Windows Live, uso apenas Linux com aMSN ou Pidgin, que me atendem muito bem.

Se quiser/puder pagar por desenvolvimento de interface, entra em contato por e-mail particular, sem enviar dados para a lista.

[]'s
          Junior Polegato


Reply to: