Perché il mio computer di destinazione .NET Remoting ha rifiutato attivamente la connessione?

Question

Sto cercando di stabilire una comunicazione .NET Remoting di base tra macchine Windows 2x 64 bit. Se Machine1 funziona come client e Machine2 come server, allora tutto funziona bene. Al contrario, si verifica la seguente eccezione:

System.Net.Sockets.SocketException: impossibile stabilire una connessione perché la macchina di destinazione l'ha rifiutata attivamente 172.16.7.44:6666

Il codice del server:

TcpChannel channel = new TcpChannel(6666);
ChannelServices.RegisterChannel(channel);
RemotingConfiguration.RegisterWellKnownServiceType(
  typeof(MyRemotableObject),"HelloWorld",WellKnownObjectMode.Singleton);

Il codice client:

TcpChannel chan = new TcpChannel();
ChannelServices.RegisterChannel(chan);
// Create an instance of the remote object
remoteObject = (MyRemotableObject)Activator.GetObject(
  typeof(MyRemotableObject), "tcp://172.16.7.44:6666/HelloWorld");

Qualche idea di cosa non va nel mio codice?

Answer 1

Supponendo che gli stessi binari / configurazioni funzionino in un modo ma non nell'altro mi direbbe qualcosa di sbagliato nel lato della rete della casa per cominciare.

• Stai utilizzando gli indirizzi IP: ricontrolla gli indirizzi associati sulla macchina di destinazione con config / code con IPCONFIG / ALL.
• Il " server " la macchina ha più schede di rete? Il servizio è associato a una scheda di rete non ad esempio?
• il ping del server ti dirà che ICMP è instradabile tra le macchine. Puoi creare richieste di orientamento della sessione, ad es. apertura dei percorsi UNC sul server dal client.

Oltre Firewall, l'unica altra connessione che ho rifiutato è stata:

• Risoluzione dei nomi: la voce host preesistente era errata. Non dovrebbe essere un problema qui.
• Orientamento IPSEC: politiche diverse tra macchine impedivano all'una di accettare connessioni in entrata dall'altra. Possibile se lavori in un ambiente sicuro aziendale. Se lavori in un ambiente IPSec, controlla cose semplici come orologi, certificati di macchina validi. Tutto ciò può impedire la creazione di sessioni IPSec.
• problema di stress - Stack IP esaurito blocchi di controllo TCP gratuiti a causa di un'errata configurazione di un server. Allo stesso modo sembra che non sia possibile stabilire alcuna connessione, probabilmente non il problema.

Comincerei con Firewall 1st - impostando la politica per esentare le richieste in entrata su quel socket, fidandomi di tutti i socket dall'IP di origine o disabilitandolo tutti insieme. (personalmente quest'ultimo è veloce e sporco come test, ma farei il primo in un ambiente di produzione)

Oltre a questi registri eventi, audit trail se il firewall è attivato ma perforato. Netmon ecc. Diventano tutti tuoi amici.

Answer 2

Windows Firewall? (L'autore della domanda dice che non è così.)

Per rintracciare i problemi di connessione si applica l'approccio standard (applicare in qualsiasi ordine):

• ping the machine
• ricontrolla se qualche processo è realmente in ascolto nella porta 6666 ( netstat -an )
• telnet la macchina sulla porta 6666
• prova a utilizzare un servizio diverso sulla macchina.
• controlla se alcune configurazioni sconvolgono il processo del server in ascolto su 6666 e causano il rifiuto. (non so se ciò è possibile con il remoting .NET)
• guarda la comunicazione con la macchina usando uno sniffer di pacchetti (Packetyzer, per esempio) per scoprire cosa sta succedendo a livello TCP / IP.
• forse i componenti attivi dell'infrastruttura di rete tra server e client (switch di livello 3, firewall, router NAT, ecc.) interferiscono