Sono in esecuzione Windows Server 2008 R2, abbiamo un'applicazione che si collega da (si lega a) un IP pubblico sul server a 127.0.0.1:8334 [si connette a un servizio in ascolto su 0.0.0.0:8334]
In Windows 2003, non ci sono stati problemi con questo. Possiamo collegarci usando TCP da 1.2.3.4 [es.] A 127.0.0.1:8334 bene.
In Windows 2008, troviamo che le connessioni TCP dall'ip pubblico, ad es. Da 1.2.3.4 a 127.0.0.1:8334, falliscono, anche. ma il servizio accetta connessioni da 127.0.0.1 a 127.0.0.1:8334 e da 127.0.0.1 a 1.2.3.4:8334.
Ho provato a disattivare il firewall di Windows, a configurarne la registrazione ecc. (Non sono state visualizzate voci di registro utili), senza risultato. È un problema con il nuovo stack di rete?
modifiche
1.2.3.4 sta tentando di connettersi a localhost [127.0.0.1] sulla stessa macchina
Il file Hosts è il file host predefinito di Windows 2008.
Informazioni sul controllo di loopback, interessanti. Provato ... non ha funzionato. È stato effettuato un controllo incrociato per verificare che l'ID abbia fatto tutto correttamente.
Mi chiedo se esiste una soluzione che utilizza NAT o un altro modo per inoltrare le porte: se inoltro 127.0.0.1:port a 1.2.3.4:port, funzionerebbe? Dato che l'app è in ascolto su 0.0.0.0:port rileverà le connessioni su 1.2.3.4:port
Il file HOSTS contiene localhost 127.0.0.1 - tuttavia, il file hosts viene utilizzato solo nelle ricerche di nomi host. In questo caso, la nostra applicazione non cercherebbe alcun nome host, poiché l'indirizzo IP 127.0.0.1 è codificato (anziché il nome host localhost). Quindi il file HOSTS non entrerebbe in gioco qui.
Per quanto riguarda le porte sopra la 1024 [pensi di riferirti al problema MaxUserPort forse?] L'ho provato provando una semplice connessione alla porta 445 - funziona da 127.0.0.1, non funziona quando mi collego dall'IP sorgente 1.2.3.4. 445 è un servizio Windows standard, quindi dovrebbe funzionare!
Attualmente non eseguire NAT o RRAS sulla macchina ... mi chiedevo se ci fosse un modo per eseguire il reinstradamento - Immagino che non funzionerà poiché lo stack TCP / IP rifiuterà il pacchetto prima che raggiunga l'interfaccia di loopback per reindirizzare.
Stampa del percorso che avevo verificato: sembra che gli IP pubblici siano stati instradati per primi, quindi infine 127.0.0.0 netmask 255.255.255.0 e 127.0.0.1 netmask 255.255.255.255 entrambi al loopback.
Modifica Sembra che abbia trovato la risposta sul motivo del problema. Ho usato eventvwr.msc, abilitato la registrazione di Winsock, disattivato altri servizi, ho appena provato questo test di connessione. Si è verificato un errore che in esadecimale è stato mappato su STATUS_INVALID_ADDRESS_COMPONENT quando l'ho cercato su Google.
Mi ha portato a: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba
Il che ha confermato che si tratta di una modifica in base alla progettazione in WFP per Vista / 7 / Server 2008 [piattaforma filtro Windows].
[Vedi risposta di Anupama Vasanth]
Sembra che dovrò percorrere la strada difficile e riscrivere il codice [difficile perché significa trattare con i gestori!]
Grazie per avermi aiutato a individuare / confermare il problema!