Perché SSH tramite IP remoto è più veloce dell'IP locale?

Ho un server Linux in esecuzione da casa mia, con una configurazione URL DynDNS che punta al mio indirizzo IP pubblico.

Una delle cose che ho notato è usare l'indirizzo remoto come url.dyn-dns.tv o il mio IP pubblico si collega più velocemente al server rispetto al mio locale 192.168.xx.xx.

Qualcuno ha qualche idea del perché questo potrebbe essere?

linux ssh linux-mint

— Grant
fonte

perché la taglia? vuoi dire che il problema non è il DNS, o vuoi solo avere più informazioni perché la ricerca inversa DNS mancante può rendere SSH lento?

— mihi

Bounty perché volevo altre informazioni su di esso. Non dicendo che non era DNS, solo le risposte originali non lo descrivevano in dettaglio e ero curioso di sapere se c'erano delle correzioni.

— Grant

Qual è la tua rotta / gateway predefinita? È diverso dal tuo server Linux? Quindi potrebbe essere correlato alla tua cache ARP.

— artistoex

Quali dispositivi ethernet / layer 2 sono coinvolti? Come sono connessi l'uno con l'altro? Forse questo fenomeno non può essere spiegato solo nelle materie del livello 3/4/7.

— artistoex

Se è dns, ci sono due correzioni: Configura DNS inverso per gli IP LAN o disattiva la registrazione di DNS inverso sul server: D (o chiedi al tuo provider di disabilitare il DNS inverso per il tuo IP pubblico, in entrambi i casi sarà lento. ..)

— mihi

Risposte:

tl; dr Risolve la configurazione del resolver DNS sul server. (una soluzione alternativa è disattivare le ricerche inverse in SSHD ma è meglio correggere ciò che è rotto)

Risposta originale

Qualcuno ha qualche idea del perché questo potrebbe essere?

Non proprio ma ecco un aneddoto che potrebbe aiutare:

In passato, con un protocollo diverso, quando una connessione impiega un tempo insolitamente lungo per essere stabilita, ho trovato che una causa è il timeout del DNS mentre il server prova a cercare il nome di un indirizzo IP in modo che possa registrare il nome del client nei suoi log . Se l'indirizzo IP del client non è correttamente noto al servizio DNS locale e il DNS non è configurato correttamente, il server può attendere a lungo il timeout del DNS.

Il modo per cercare questo tipo di effetto è di eseguire gli sniffer di rete, inizialmente sul client ma anche sul server, quindi potresti vedere il traffico di rete relativo alla connessione, che richiede molto tempo per ottenere una risposta, o che non riceve risposta (è possibile che vengano visualizzati nuovi tentativi)

tcpdump e wireshark sono buoni.

Aggiornamento 1

Al cliente con il ritardo nella connessione

trova l'indirizzo IP del client
- Su Windows, apri una finestra del prompt dei comandi e digita ipconfig
- Su Linux, apri una finestra di terminale e digita ifconfig -a
opzionalmente confermare che è possibile cercare rapidamente l'indirizzo IP del server
- Su Windows nslookup servername
- su Linux dig servername o host servername se il tuo non ha scavare

Al server

cercare il nome del cliente
- registrare /etc/resolv.conf per l'indirizzo del primo server dei nomi DNS
- genere dig -x 192.168.n.m @nameserver o host 192.168.n.m server dove 192.168.n.m è sostituito dall'effettivo indirizzo IP del client e il server dei nomi è l'indirizzo IP del server dei nomi.
- ripetere per altri server dei nomi elencati in /etc/resolv.conf

il server dovrebbe ricevere una risposta in millisecondi. Con una configurazione DNS rotta ci vorranno diversi secondi per scadere.

buona config

# time host 192.168.3.4
Host 4.3.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

real    0m0.130s
user    0m0.000s
sys     0m0.020s

cattiva configurazione

# echo nameserver 1.2.3.4 > /etc/resolv.conf
# time host 192.168.3.4
;; connection timed out; no servers could be reached

real    0m10.010s
user    0m0.000s
sys     0m0.010s

Notare il ritardo di 10 secondi. Ciò significa che qualsiasi servizio SSH che desidera avere nomi di client nei suoi log impiegherà 10 secondi per impostare una connessione SSH.

Aggiornamento 2

Si scopre che Q è (probabilmente) un duplicato esatto di Perché il prompt "password" richiede sempre l'uso di SSH nel mio server Ubuntu 9.05?

Soluzione

Correggere la configurazione del resolver DNS sul server.

— RedGrittyBrick
fonte

È quasi certamente un problema DNS. L'IP remoto ha un DNS valido. L'IP interno no.

— David Schwartz

Un problema DNS non significherebbe alcuna connessione, mentre il problema è connessione lenta .

— harrymc

@harrymc: ero solito amministrare il DNS per una società Fortune-100. Ho usato analizzatori di rete su problemi con questo sintomo. Questo succede davvero. Il client può cercare l'indirizzo IP del server, il server è in attesa di scoprire il nome del client dall'indirizzo IP del client solo per scopi di registrazione.

— RedGrittyBrick

Ho intenzione di indovinare che non si sta eseguendo un DNS locale, quindi quando il server ssh tenta di eseguire una ricerca DNS inversa è in attesa di un timeout. Quando ci si connette all'indirizzo esterno, viene eseguito il NATted tramite un indirizzo IP che supera il raduno DNS.

Per disattivare le ricerche DNS inverse, dovrai modificare il tuo file sshd_config e trovare la riga "UseDNS" e impostarlo su "no". (Dovrai riavviare sshd perché diventi effettivo.) In alternativa puoi configurare il tuo server DNS per la tua sottorete locale. (DNSMasq è un gioco leggero con cui giocare se non vuoi scherzare con BIND)

— las
fonte

Potresti provare a chiamare ssh con l'opzione verbose massima: ssh -v -v -v.
Questo potrebbe dare alcune informazioni utili.

Una spiegazione che posso pensare è se il tuo server è in ascolto su iPv4, ma lo hai ancora iPv6 abilitato sul tuo sistema locale. Il tempo di attesa sarebbe allora quando ssh sta cercando invano per accedere al server su iPv6, quindi si arrende e prova con successo iPv4.

In ogni caso, suggerisco di verificare quali schede di rete sono abilitate e disabilitare quelle che sono inutili.

— harrymc
fonte