Mistério firewall? Lista de verificação para diagnosticar conexões de entrada bloqueadas

Question

Estou executando um servidor da Web para desenvolvimento em um Lenovo Thinkpad T420s e não consigo me conectar a ele de três dispositivos separados (desktop, iPad e telefone, respectivamente).

O laptop e outros dispositivos estão conectados a um roteador que executa o DD-WRT (com fio da área de trabalho, tudo o resto sem fio). Eu já determinei o seguinte:

Lista de verificação para alguém com problemas para se conectar a um servidor local

• O servidor está em execução e está atento a conexões (testadas via http para localhost).
• netstat -a -n -b mostra que algo está escutando na porta correta.
• O Firewall do Windows é completamente desativado em redes públicas, privadas e de domínio.
• O IP do host é estático.
• Outros servidores no host também não funcionam (tentei um na porta 8000, 1515 e também teste ping).
• Na outra máquina (desktop), consegui hospedar um servidor e responder aos pings do meu telefone. Curiosamente, também consegui acessar o servidor de desktop do meu laptop e ipad, mas apenas um segundo depois de "acordar" o servidor com uma solicitação do meu telefone primeiro. (Isso não funcionou para o servidor no laptop.)

Além das correções comuns, eu tentei várias outras coisas:

Lista de verificação para quem tentou todas as coisas acima

• Certificar-se de que o isolamento do AP esteja desativado ( link )
• Reparando o Winsock2 ( link )
• O VIP Access Connections não está instalado, tanto quanto eu posso dizer (consulte aqui para outra pessoa encontrar este blocos de entrada conexões)
• Farejando ambas as conexões de entrada usando o Wireshark (isso indicou que a hospedagem não ouviu nenhum pedido recebido quando eu fiz um do meu telefone.)
• Farejar as conexões de saída tentando acessar o host da minha área de trabalho e farejando na área de trabalho mostrou que não havia nenhuma solicitação de saída HTTP, apenas uma série de TCPs:

Minha pergunta é dupla:

1. Existe algo específico em um Thinkpad T420s que pode estar bloqueando as conexões de entrada secretamente?
2. Qual é a melhor maneira de sistematicamente descobrir por que as conexões de entrada não estão sendo respondidas? (Veja acima para resposta)

Qualquer ajuda sobre isso seria muito, muito apreciada. Estou ficando sem ideias!

Atualização: funciona agora, mas não sei por quê. Espero que esta lista de verificação seja útil para qualquer outra pessoa que tente acessar um servidor da Web localmente.

    

Answer 1

1. Existem vários firewalls de software e funções de roteador DD-WRT que podem bloquear as conexões de entrada. O isolamento de ponto de acesso e o firewall de desativação teriam sido minhas primeiras duas recomendações. Meu próximo passo seria examinar melhor a configuração do roteador. Meu instinto diz que, se você tivesse uma conexão com fio para o laptop e a área de trabalho, funcionaria entre os dois.

2. Uma ótima ferramenta para solucionar sistematicamente problemas de conexão seria um sniffer de pacotes como o wireshark. Neste ponto, você está adivinhando o que está acontecendo na rede. Em seguida, alternando várias configurações na esperança de confirmar um palpite. Por que adivinhar quando você pode olhar e ver? A captura de pacotes lhe dará uma leitura ao vivo do que está acontecendo. Você pode descobrir que o pacote TCP SYN nunca alcança o servidor ou alcança o servidor, mas nenhuma resposta é emitida. Alternativamente, poderia ser algo completamente diferente de um problema de resolução de nome / ip / arp. Um sniffer não conserta nada sozinho, mas deve lhe dar uma ideia muito melhor sobre o que está acontecendo agora.

Tentar interpretar uma captura de pacote pode ser um pouco intimidador no começo, tente se concentrar no básico e ignorar as partes mais complexas.

Analisador de Protocolos Wireshark

Editar: Só queria acompanhar agora que você adicionou a captura de tela de captura de pacote. É significativamente mais claro o que está acontecendo. Um dos desafios de usar uma ferramenta como a wireshark é entender como os protocolos devem ser . Como o HTTP é executado sobre uma conexão TCP normal, o que você vê aqui é uma série de falhas para configurar uma conexão TCP na porta 1515. O motivo pelo qual você não vê HTTP é que a conexão TCP falhou antes da conversação entre cliente e servidor poderia chegar tão longe. Eu andarei com você através do número do pacote através das duas primeiras tentativas:

packet(204) .150 -> .151 [SYN] "Hi I'd like to connect to port 1515"

packet(207) .151 -> .150 [RST, ACK] "Not listening. There's no port 1515 here. Buzz off ok?"

packet(208) .150 -> .151 [SYN] "Hi I'd like to connect to port 1515"

packet(209) .151 -> .150 [RST, ACK] "Not listening. There's no port 1515 here. Buzz off ok?"

etc...

Um sinalizador RST em uma conversa TCP é um fechamento forçado. É mais rude do que uma bandeira FIN normal que encerra normalmente uma conversa. Isso geralmente significa que há uma porta de bloqueio de firewall 1515 ou nada está escutando na porta 1515. Eu vejo [RST, ACK] mais comumente de servidores que não têm um serviço escutando nessa porta, enquanto os firewalls tendem a apenas RST ou buraco negro (sem resposta) o tráfego.

Agora que está funcionando, faça outra captura para ver como é uma conexão bem-sucedida. Deve ser algo nos moldes de:

.150 -> .151 [SYN] "Hi I'd like to connect to port 1515"

.151 -> .150 [SYN, ACK] "Acknowledged, here's my buffer size"

.150 -> .151 [ACK] "Works for me"

.150 -> .151 [ACK][HTTP/GET] "Requesting html via HTTP"

.151 -> .150 [ACK][HTTP/1.1 200 OK] "Here is the html you requested"

series of HTTP conversations riding on top of TCP ACKs

.150 -> .151 [FIN] "Thanks server I'm all done now close connection"

.151 -> .150 [ACK, FIN] "I agree we should close connection"