Connexion refusée - NetTcp service WCF du travail - client qui se connecte via VPN

Question

Voici le scénario: Une machine client est connecté au 'réseau de travail' via VPN (Cisco VPN Client). Le réseau de travail héberge une machine qui a un service WCF avec NetTcp obligatoire. Le client tente de se connecter à ce service et obtient une exception comme suit:

  

Impossible de se connecter à   net.tcp: // WorkMachine: 2010 / SOMESERVICE.   La tentative de connexion a duré une   laps de temps de 00: 00: 01,3180754. TCP   Code d'erreur 10061: Pas de connexion pourrait   être fait parce que la machine cible   activement refusé WorkMachine. 2010

Ce que j'essayé:

1. Changé le groupe de travail du client machine au réseau de travail groupe de travail
2. domaine / nom d'utilisateur / mot de passe Ajout de la voûte Mot de passe réseau Windows, afin qu'il puisse être utilisé pour connecter
3. Changé le chemin de service WCF avec une adresse IP au lieu du nom WorkMachine
4. machine client Vérifié pare-feu et a ajouté pour permettre au client WCF au travers

Tout ce qui précède a échoué

et ne fonctionne pas. Quelqu'un at-il rencontré des problèmes similaires?

La machine cliente est sous Windows 7

SecurityMode du service WCF est réglé sur NONE -. Si cela ne devrait pas être un problème

Toutes les idées seront utiles

Answer 1

Vous devrez peut-être fournir des informations d'identification de client explicitement par votre objet proxy.

Supposons que l'objet proxy dans le code ci-dessous met en oeuvre l'une des interfaces de ClientBase.

proxy.ClientCredentials.Windows.ClientCredential.UserName = "clientaccount";
proxy.ClientCredentials.Windows.ClientCredential.Password = "S3cr3t1337Pwd";

Answer 2

Pouvez-vous - seulement à des fins de test - exposer le même service sur la même machine en utilisant un point de terminaison HTTP, et essayez de vous connecter à celui de votre client VPN?

NetTcp est un excellent choix derrière le pare-feu d'entreprise - ne savent pas comment le client VPN Cisco pourrait causer des problèmes ici, qui pourraient ne pas apparaître lors de l'utilisation d'un protocole HTTP. Juste une supposition sauvage pour l'instant, mais si vous avez rien d'autre à aller plus loin, faire un essai!

Marc

Answer 3

Juste une autre pensée pour aider avec le débogage de ce genre de problèmes, en utilisant CMD exécuter « netstat » (vous pouvez ajouter l'option -o et trouver le numéro de processus lié aussi) et voir si le port en question est actuellement ouvert , si ce ne vous avez un problème avec le SMSvcHost.exe (ce qui est le processus Windows pour la gestion d'un service hébergé IIS TCP).

Je l'ai eu ce problème avant et rectifié en redémarrant les services suivants (vous aurez évidemment besoin d'examiner attentivement si vous avez affaire à un système de production en direct):

NetTcpActivator (adaptateur Net. Tcp regarder) NetTcpPortSharing (Net. Tcp Port Service de partage)

et, éventuellement, le cas échéant:

NetMsmqActivator (Net. Tuyau adaptateur Listener) NetPipeActivator (Net. Tuyau adaptateur Listener)

Espérons que cela aide quelqu'un!

J.