Impossibile accedere al servizio esterno dalla LAN interna

Ho uno strano problema di port forwarding. Ho provato ad aprire la mia porta 22 sulla rete esterna. Sono stato in grado di accedervi fintanto che non sono all'interno della LAN. Posso accedervi dal mio ufficio per esempio. Ma dall'interno della LAN, posso accedere alla porta usando l'ip locale, ma non posso accedere alla porta usando l'IP esterno. È come se il router stesse bloccando il loopback. Ho controllato tutte le impostazioni del mio router, disattivato tutto ciò che riguarda firewall / filtro. Qualche idea?

Supponendo che Spiff sia corretto e che il tuo router non sia in grado di gestire il port forwarding verso l'ip esterno dall'interno della rete, c'è un piccolo problema (e suona come questo è il caso);

È possibile modificare il file hosts, che si trova in / etc / hosts nella maggior parte dei sistemi unix e in C: \ Windows \ system32 \ drivers \ etc \ su Windows.

se aggiungi

192.168.0.15  example.com

in quel file, il tuo computer andrà all'ip spesificato ogni volta che provi ad accedere a example.com. Ovviamente dovrai farlo su ogni computer che desideri utilizzare all'interno della rete.

Puoi consultare l'articolo di Wikipedia per maggiori dettagli su dove trovarlo: https://en.wikipedia.org/wiki/Hosts_file

Dato che hai citato il port forwarding, suppongo che il tuo gateway home agisca come un gateway NAT, o più specificamente NAPT. Quello che stai cercando di fare è chiamato "forcina NAT" o "forcina NAT", in riferimento al modo in cui una forcina letterale si raddoppia su se stessa (la stessa allusione è usata dal termine "tornante" per una curva stretta in cui una strada raddoppia su se stessa).

Alcuni gateway NAT sono una schifezza e non supportano il tornante. Potrebbe essere il momento di esplorare le opzioni di aggiornamento.

C'è una vera risposta semplice a questa. Il NAT si sta mettendo in mezzo.

1. Il computer apre una connessione a [ExternalIP]
2. Il router inoltra tale connessione a [SSHInternalIP]. Il tuo server SSH vede una connessione da [YourInternalIP].
3. Il tuo server SSH invia i suoi pacchetti a [YourInternalIP].
4. Il tuo computer vede uno strano pacchetto proveniente da un IP con cui non ha mai parlato e lo scarta.
5. La connessione a TCP / 22 non riesce perché l'handshake a 3 vie TCP non si completa mai.

Stai cercando di parlare con un IP pubblico, ma le risposte provengono da un IP interno. Il tuo computer non può far funzionare i due insieme. La soluzione è utilizzare l'IP interno ogni volta che ti trovi dietro il router. Risolvo questo problema sui miei laptop usando diverse stringhe di connessione ssh a seconda di dove mi trovo.

Da quello che ho capito dall'esecuzione di un router OpenBSD con NAT, Spiff ha ragione nella sua risposta: il problema che stai riscontrando è causato dal gateway NAT che non supporta ciò che stai cercando di fare.

La tua stazione di lavoro sta inviando pacchetti con un IP di origine di un indirizzo interno (diciamo, 10.0.0.2), ma l'indirizzo di destinazione è il tuo IP esterno. Quando i pacchetti arrivano al server (SSH?) Sulla porta 22, il server risponde direttamente alla workstation e non si verifica alcun NAT; ora, quando la workstation riceve una risposta da 10.0.0.3 quando si aspettava una risposta dal tuo indirizzo esterno, rilascia i pacchetti.

Sembra un problema banale a portata di mano, ma può essere risolto aggiornando il file HOSTS della stazione di lavoro, aggiungendo un server DNS interno (o modificando le voci del server DNS) o creando una regola NAT per gestire internal-> external-> internal traffico.