Como você depura redes domésticas quebradas?

Question

Tenho uma pequena rede doméstica e estou com problemas para acessar um dos computadores dessa rede. A rede doméstica é NAT e configurei um encaminhamento de porta e um DNS dinâmico.

• rye fica na minha rede doméstica. A porta 2222 voltada para o público do meu roteador é encaminhada para a porta 22 do rye .
• sorghum fica na minha rede doméstica. A porta 22 voltada para o público é encaminhada para a porta 22 de sorghum .
• teff fica em uma rede externa.

Eu agora apresento o seguinte cenário estranho:

1. Posso usar o SSH de teff a dmwit.duckdns.org:2222 , por isso acredito que o DNS dinâmico está funcionando corretamente, o encaminhamento de porta para rye está funcionando corretamente e rye está aceitando conexões de outros computadores corretamente não está bloqueando as coisas no nível do firewall).
2. Posso usar o SSH de rye a dmwit.duckdns.org:22 , por isso acredito que o encaminhamento de porta para sorghum está funcionando corretamente e sorghum está aceitando conexões de outros computadores corretamente.
3. De rye , pedir ao Netcat para se conectar a uma porta em sorghum que está sendo bloqueada pelo sorghum do firewall resulta em "Nenhuma rota para hospedar", enquanto de teff pedindo para a Netcat se conectar a dmwit.duckdns.org:22 resulta em "Tempo limite da conexão esgotado", portanto, acredito que o firewall de sorghum não esteja bloqueando essa conexão.
4. Não consigo SSH de teff a sorghum (a conexão expira).

Acho isso um pouco desconcertante; Evidência sugere que cada peça na cadeia está funcionando corretamente, mas toda a cadeia está quebrada. Eu tenho duas questões concretas que são um pouco não relacionadas entre si:

1. Como esse tipo de coisa pode ser mais depurado? Quais ferramentas posso usar para encontrar mais detalhes sobre o que está errado?
2. Como faço para corrigir isso para que eu possa ssh de teff para sorgo?

EDITAR: Encontrei um questão vagamente relacionada que sugeria tentar o Traceroute. Em teff , posso ver uma diferença significativa entre as saídas do Traceroute para as portas 22 e 2222:

% traceroute -p 2222 -T dmwit.duckdns.org
traceroute to dmwit.duckdns.org (75.164.159.92), 30 hops max, 60 byte packets
 1  gw-40.galois.com (192.168.40.1)  13.722 ms  13.723 ms  17.016 ms
 2  66.162.129.25 (66.162.129.25)  17.957 ms  18.106 ms  18.289 ms
 3  64-129-238-66.static.twtelecom.net (64.129.238.66)  18.949 ms sea2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.243.34)  19.250 ms 64-129-238-66.static.twtelecom.net (64.129.238.66)  19.242 ms
 4  64.132.69.2 (64.132.69.2)  20.052 ms  20.291 ms  20.284 ms
 5  ptld-agw1.inet.qwest.net (67.14.49.2)  22.658 ms  22.942 ms  22.932 ms
 6  207.225.86.146 (207.225.86.146)  22.924 ms  8.583 ms  8.591 ms
 7  * * *
 8  75-164-159-92.ptld.qwest.net (75.164.159.92)  31.056 ms  29.508 ms  29.714 ms
% traceroute -p 22 -T dmwit.duckdns.org -m 60
traceroute to dmwit.duckdns.org (75.164.159.92), 60 hops max, 60 byte packets
 1  gw-40.galois.com (192.168.40.1)  1.660 ms  5.667 ms  5.912 ms
 2  66.162.129.25 (66.162.129.25)  5.901 ms  12.563 ms  12.555 ms
 3  64-129-238-66.static.twtelecom.net (64.129.238.66)  14.227 ms sea2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.243.34)  12.796 ms  12.787 ms
 4  64.132.69.2 (64.132.69.2)  12.778 ms  12.769 ms  12.762 ms
 5  ptld-agw1.inet.qwest.net (67.14.49.2)  13.955 ms  13.946 ms  13.937 ms
 6  207.225.86.146 (207.225.86.146)  13.931 ms  10.297 ms  10.256 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
<snip>

O segundo continua assim por mais 20 linhas (e continua mais se você aumentar a contagem máxima de saltos). Eu não tenho 100% de certeza de como interpretar isso, então adicione uma terceira pergunta:

3. O que essa saída de traceroute significa?

Answer 1

Você verificou que não há bloco SSH de saída no final do teff? Você demonstrou que poderia se conectar a um sistema doméstico na porta 2222 do teff, mas poderia haver um bloco de saída na porta 22. Se você não verificou se as conexões de porta 22 de saída do teff são possíveis, tente ssh github.com do teff. Você deve ver um aviso sobre a chave do github.com. Você verificou que tem uma regra de firewall apropriada no ponto de demarcação entre a rede externa e sua rede doméstica interna que permitirá uma conexão de entrada do endereço IP da teff na porta 22? Vejo que o dmwit.duckdns.org não está aberto à conectividade da Internet na porta 22 e parece que você só verificou que o sorgo está acessível a partir de um endereço interno da rede doméstica, o que não significa necessariamente que exista uma regra de firewall apropriada que permitirá conexões de porta 22 de outro lugar. Olhe para o log do firewall no sorgo; você vê alguma coisa no log indicando uma tentativa de se conectar à porta 22 do teff? Você poderia tentar uma conexão de um sistema diferente do teff usando o teste de conectividade do servidor SSH e examinar o log do firewall do sorgo depois para ver se alguma atividade foi registrada, se o sorgo deve estar pelo menos acessível na porta 22 da Internet, mesmo que o firewall esteja bloqueando a conexão.

    

Answer 2

Tente configurar o sshd para escutar em outra porta diferente da porta 22 no sorgo (> 1024). Isso pode ser algo específico, seja na saída do lado do teffs ou na entrada do lado do centeio / sorgo. Alguns provedores bloqueiam certas portas reservadas, um bom exemplo seria a porta 25 smtp, pois nenhum provedor gosta de lidar com spammers que examinam suas redes em busca de retransmissão aberta. De qualquer forma, estou convencido de que este pode ser o motivo, a porta está aparecendo como filtrada em um teste de sin básico que provavelmente significa que poderia estar sendo filtrada no nível do provedor no lado de centeio / sorgo (ingresso)

"Filtrado significa que essas portas estavam identificado como sendo interrompido por algo ao longo do caminho da rede. Pode ser um firewall no destino, mas também pode estar filtrando regras em qualquer um dos hosts intermediários entre as máquinas de auditoria e de destino. "

Consegui confirmar o mesmo comportamento de filtragem com vários endereços na mesma rede. Eu sugiro ler as políticas do AUP do seu provedor de serviços, já que provavelmente você estará impedido de usar a porta padrão. Boa sorte para o senhor.

    

Answer 3

1. você usaria ferramentas como tcpdump (8) e / ou wireshark (1) para ver quais pacotes estão chegando e partindo de hosts problemáticos. Portanto, se você vir o pacote TCP SYN chegando, mas nenhuma resposta for enviada, isso é devido ao firewall local (ou roteamento). Mas se você não vir o pacote TCP SYN chegando, significa que algum firewall o descartou antes de chegar ao seu host. Por exemplo, sua configuração de firewall padrão do roteador, ou seu ISP que considere a execução de serviços em seus hosts como violação de seus ToS e / ou risco de segurança.
2. Sugiro alterar a porta pública 22 para, por exemplo, 2223 . Se funcionar, isso significa que o firewall do provedor de serviços de Internet ou o roteador doméstico bloqueia a porta 22.
3. significa que o roteador no salto 6,7 ou 8 (é ambíguo devido ao roteador silencioso em 7) está descartando pacotes com a porta de destino 22 (e não aqueles com a porta 2222). Novamente, pode ser o firewall do seu provedor ou o firewall do seu roteador doméstico ou a configuração local (por exemplo, o roteador pode reservar a própria porta 22 para gerenciamento remoto e desconectar essa conexão de portas externas). Eu suspeito de roteador local. Novamente, o mais fácil de verificar é mudar a porta voltada para o público em 2223 para sorghum