Impossibile eseguire il port forwarding nella rete NAT a 2 strati con TL-WR340G


0

Oggi ho dovuto dividere la mia LAN. Il mio ISP non mi permette di controllare abbastanza il NAT / gateway, quindi ho appena creato il mio NAT dietro ISP NAT. E sto cercando di farlo funzionare.

Al momento ho bisogno di accedere a un server SSH di Raspberry Pi dall'esterno.

  • 192.168.8.0 è LAN offerta dal mio ISP
  • 192.168.9.0 è LAN offerta da un modello di router NAT wireless TL-WR340G da TP-Link

Raspberry Pi ha il suo indirizzo IP statico ed è pronto ad andare. E DEVE essere collegato al router TP-Link

Ho già configurato il port forwarding DMZ dall'esterno sul mio gateway ISP (fortunatamente posso controllarlo) e ho verificato, cambiando l'IP al mio laptop collegato direttamente al modem ISP, che il port forwarding funziona da quel lato.

Va bene...

Poi sono passato all'amministratore del router TP-Link e ho impostato il port forwarding all'indirizzo Raspberry IP. Ho impostato il solito: porta di servizio? 22, indirizzo IP? 192.168.9.x e doppio controllo, protocollo? tcp o entrambi. abilitare? ovviamente.

Ma il problema è che il router wifi non inoltrerà mai nulla alla sua LAN. Sono sicuro delle cablature. Sono in grado di raggiungere Raspberry dal suo indirizzo LAN. Ho determinato che il router potrebbe essere configurato in modo errato perché Ho collegato il mio laptop al modem ISP, ho ottenuto un indirizzo .8.x e ho provato a ssh a .8.y dove y è l'indirizzo IP WAN del router TP-Link . Pazzo. Rifiuterà sempre la connessione.

Ho provato ad abilitare DMZ a Raspberry, quindi il doppio forwarding dovrebbe avvenire su qualsiasi porta. Senza fortuna. Ho provato a riavviare più volte, ma il router sembra non andare.

Sono sicuro di cablaggi perché quando ho fatto la migrazione ho spostato tutto da modem ISP alle porte LAN del TP Link e collegato la WAN di TP Link a una porta LAN del modem ISP. Tutti i dispositivi dietro TP Link ottengono un indirizzo .9.x corretto.

C'è qualcosa di più da controllare sulle impostazioni del router? Qualcosa che potrei aver perso?

Sto diventando pazzo perché domani lascerò questo posto e dovrò riconnetterlo in futuro tramite OpenVPN. Non posso provare un altro router, ho solo questa attrezzatura in questo momento della giornata. Il motivo per cui non si controllano le route statiche sul modem ISP, altrimenti il ​​funzionamento di Raspberry sul modem ISP con il port forwarding rende anche openvpn. Ma deve lavorare in modo bidirezionale e trasparente.

Risposte:


0

Sto facendo alcune supposizioni qui.

Si vede che si sta descrivendo una rete doppiamente NATED, quando il router dell'ISP fornisce una rete privata di 192.168.8.xxx, a cui è stato aggiunto un altro router NAT che fornisce un'altra subnet privata numerata 192.168.9.xxx.

Se stai usando il port forwarding inword, sarebbe saggio assegnare indirizzi IP statici al tuo TL-WR340 e al tuo Raspberry Pi.

Il router di Yur ISP avrà anche un indirizzo Internet esterno. Ne avrai bisogno per arrivarci da internet. Tieni presente che gli ISP ofen non forniscono un indirizzo Internet statico a meno che non ne venga pagato uno, pertanto è probabile che tu abbia un indirizzo che può cambiare. Potrebbe essere necessario pianificare per quello. Google "DNS dinamico"

Supponiamo che il tuo router ISP abbia un hostname internet di mypc.myisp.ru e che tu possa amministrare il port forwarding su di esso.

Scegli un numero di porta per A., ​​ad esempio 12345, in quanto il tuo ISP potrebbe impedirti di inoltrare 22. È un po 'di sicurezza anche per obsurity. Non molta protezione, ma alcuni.

Il tuo obiettivo è quello di ssh to you Pi di ssh-ing a mypc.myisp.ru:12345. forse da un comando come

ssh pi@myisp.mysip.ru -p 12345

Il router ISP deve essere impostato per l'inoltro all'indirizzo IP esterno del TL-WR340G, l'indirizzo sulla sottorete dei fronti del router dell'ISP. Sarà più facile se lo fai statico

Supponiamo che sia 192.168.8.123

Dato che questo è il tuo dispositivo, assumerò che possa inoltrare la porta 22.

Quindi sul router ISP, istruirlo per inoltrare la porta 12345 alla porta 22 su 192.168.8.123.

Ora il tuo TL-340G vedrebbe una connessione in entrata sulla sua porta 22.

Quindi è necessario andare nelle pagine di amministrazione del TL340G e istruirlo a inoltrare la porta 22 alla porta 22 in corrispondenza di un indirizzo configurato dal proprio Raspberry Pi, ad esempio 192.168.9.55

Quindi in pratica è necessario configurare il port forwarding due volte.

Se non è possibile amministrare il port forwarding del router dell'ISP, è necessario iniziare a guardare UPNP per ottenere la porta in ingresso.


Ok, forse non ho spiegato tutto. Mi sto concentrando sul secondo port forwarding perché il primo funziona. E ho già dyn dns da molto tempo. In effetti oggi ho collegato il modem Pi al ISP e ho funzionato come un fascino dall'esterno (anche il vanity dns funziona). Ma stasera avevo bisogno di cambiare l'intero setup a causa di una storia diversa. E ho ancora bisogno di avere quel Raspberry Pi accessibile dall'esterno come lo era stamattina. Quindi, quando ho scoperto che Pi non stava ottenendo connessioni da al di fuori Ho provato a controllare dentro la rete collegando la connessione al modem ISP al di fuori del NAT interno e vedere
usr-local-ΕΨΗΕΛΩΝ

"Quindi è necessario andare nelle pagine di amministrazione del TL340G e istruirlo a inoltrare la porta 22 alla porta 22 in corrispondenza di un indirizzo configurato dal proprio Raspberry Pi, ad esempio 192.168.9.55". Esattamente quello che ho fatto, senza successo. Ho fatto questa domanda per ottenere aiuto su quel dispositivo, perché qualsiasi altro avrebbe funzionato
usr-local-ΕΨΗΕΛΩΝ

Non ho esperienza su quel particolare hardware. Suggerisco di eseguire il debug della configurazione inserendo qualcosa nella rete 192.168.8.xx da cui è possibile eseguire ssh e provare direttamente al router TL340G. Magari prendi una traccia di cavi elettrici su cosa sta succedendo.
infixed

Il tuo TL340G sta usando un indirizzo statico 192.168.8.xxx per la sua porta WAN, giusto?
infixed

Un DHCP prenotazione per essere precisi. Ma ti manca il punto. È l'inoltro TL non funziona. Sto facendo il debug già dall'interno. Non preoccuparti, ho poco tempo e se non riesco a risolvere dovrò semplicemente cancellare l'attività
usr-local-ΕΨΗΕΛΩΝ
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.