Início / user-1031281

DBCL's questions

Martin Hope
DBCL
Asked: 2025-04-24 22:33:21 +0800 CST
  • 5

Resumo da questão

Estou enfrentando um atraso muito longo (~20–40 segundos) ao abrir uma nova sessão SSH ou ao usar sudopela primeira vez um terminal no meu sistema Debian 11. sudoComandos subsequentes no mesmo terminal são instantâneos, mas o atraso retorna em um novo terminal. Para sua informação, isso acontece tanto com SSH remoto quanto com SSH local ( ssh admin@localhost).

O que eu tentei

  • UseDNS noe GSSAPIAuthentication nosão definidas em sshd_config.
  • Nenhum módulo PAM personalizado ou relacionado à rede (sem pam_ldap, pam_krb5, pam_sss, etc.).
  • Comentado pam_systemd.soem sessão comum sem efeito.
  • nsswitch.conf é padrão: somente filese dnspara hosts, sem LDAP/NIS para usuários/grupos.
  • hosts está correto e inclui ambos 127.0.1.1e o IP real com o nome do host.
  • Nenhum /etc/nologinarquivo.
  • As permissões tmp estão corretas ( drwxrwxrwt).
  • Nenhuma regra access.conf.
  • profile, bash.bashrc, environment e dotfiles do usuário estão limpos ou foram movidos temporariamente.
  • Sem cotas ou problemas de espaço em disco.
  • o correio existe e é acessível.
  • passwd e group são normais.
  • Nenhuma entrada incomum em sudoers ou sudoers.d.
  • Nenhum /etc/motd.d/script MOTD ou scripts personalizados.
  • Nenhum problema com limits.conf ou limits.d.
  • Não /etc/ldap.confou /etc/sssd/sssd.confpresente.
  • systemd-logind, dbus, e polkitestão em execução e foram reiniciados.
  • Nenhum erro em dmesg, auth.log ou syslog.
  • Sem alta carga de CPU, memória ou E/S durante o atraso.
  • Nenhuma montagem de rede ou autofs.
  • As permissões pts estão corretas.
  • Os diretórios pessoais existem, têm permissões corretas e são locais.
  • O shell é bash e funciona.
  • Testado com o mínimo de usuários e sh como shell
  • straceligado sudoe sshdmostra que o atraso ocorre antes que os scripts do shell ou do perfil do usuário sejam executados.
  • straceon sshde seus filhos mostram longas esperas em select()ou read()em descritores de arquivo internos (não soquetes de rede).
  • O atraso ocorre depois que a autenticação da senha é bem-sucedida, mas antes que o prompt do shell apareça.
  • ssh -vvva saída mostra o atraso antes debug2: we sent a password packet, wait for replye depois debug1: Authentication succeeded (password).

Atualizar

  • Entropia disponível: 256
  • O hardware é Armv7 Cortex A7 dual-core 1GHz, 2GB DDR3L, o armazenamento é eMMC

Estou completamente sem ideias... O que inicialmente parecia um simples problema de DNS me deixou sem a mínima ideia do que realmente está acontecendo.

Obrigado por qualquer ajuda ou informação!

ssh
Martin Hope
DBCL
Asked: 2024-09-07 00:56:55 +0800 CST
  • 5

Descrição

Meu objetivo é fazer ping na Máquina C ( 10.223.0.7) da Máquina A ( 10.101.0.40)

Tenho 2 redes e 3 máquinas

  • Rede A:10.223.0.0/24

  • Rede B:10.101.0.0/16

  • Máquina A (o "pinger"): 10.101.0.40(no eth5)

  • Máquina B (o "roteador"): 10.101.2.97(no ens7) e 10.223.0.1(no wg0)

  • Máquina C (o "pingado"): 10.223.0.7(em wg0)

  • Habilitei o encaminhamento de IP na Máquina B, globalmente e em ambas as interfaces ens7 e wg0

  • Meu firewall está ACEITANDO regras FORWARD na Máquina B.

  • Adicionei esta regra: iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADEna Máquina B para habilitar o mascaramento

  • Adicionei esta regra ip route add 10.223.0.0/24 via 10.101.2.97 dev eth5na Máquina A para rotear os pacotes

O teste

Quando lanço o ping, isto é o que posso ver com tcpdump -nni any icmp:

Máquina A:

18:16:12.976724 eth5  Out  IP 10.101.1.40 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64

Máquina B:

18:16:12.977241 ens7  In  IP 10.101.1.40 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64
18:16:12.977287 wg0   Out IP 10.223.0.1 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64
18:16:12.978201 wg0   In  IP 10.223.0.7 > 10.223.0.1: ICMP echo reply, id 7373, seq 1065, length 64
18:16:12.978217 ens7  Out IP 10.223.0.7 > 10.101.1.40: ICMP echo reply, id 7373, seq 1065, length 64

Máquina C

18:16:12.977754 wg0   In  IP 10.223.0.1 > 10.223.0.7: ICMP echo request, id 7373, seq 1065, length 64
18:16:12.977767 wg0   Out IP 10.223.0.7 > 10.223.0.1: ICMP echo reply, id 7373, seq 1065, length 64

E nenhuma resposta está retornando para a Máquina A.

Acho que o problema está na 4ª linha do log da Máquina B. O IP do SRC é, 10.223.0.7mas na minha opinião deveria ser 10.101.2.97, o IP da Máquina B na rede ens7. Não tenho a mínima ideia do porquê disso ser assim.

Tentei adicionar essa regra de mascarada, iptables -t nat -A POSTROUTING -o ens7 -j MASQUERADEmas como esperado: isso não está funcionando.

Pergunta

Por que a máscara está funcionando na solicitação (veja a 2ª linha da Máquina B) e não na resposta (veja a 4ª linha da Máquina B)?

routing