amène aussi Remote Assistance à  créer
une entrée de table contenant tous les
détails pertinents de la requête.
Ensuite, Remote Assistance collecte
des renseignements sur l’ordinateur
du Novice pour le fichier de ticket de
requête. Ce fichier XML, qui a une extension
.msrcincident, contient des informations
permettant à  l’Expert de se
connecter au système du Novice : délai
avant expiration, références de logon,
et adresse IP du système.

Ces activités en coulisses se déroulent
paisiblement si le client a une
adresse IP routable (non privée) et si
aucun pare-feu ne bloque le port TCP
3389, que le trafic RDP de Remote
Assistance requiert. En revanche, si le
Novice, l’Expert ou les deux résident
derrière un routeur ou un pare-feu utilisant
NAT (Network Address
Translation), la situation devient intéressante
et inquiétante. Dans un tel
scénario, les adresses IP des machines
concernées sont privées, ce sont des
adresses inaccessibles par Internet cachées
derrière le pare-feu. Cette inaccessibilité
peut poser des problèmes
ou non d’après plusieurs facteurs, dont
le produit NAT spécifique impliqué.
Dans l’article Microsoft « Supported
Connection Scenarios for Remote
Assistance » (http://support.microsoft.
com/default.aspx?scid=kb;en-us;
q301529) qui décrit les scénarios supportés
et non supportés qui impliquent
divers produits NAT, la société
semble affirmer que la plupart des scénarios
fonctionneront. Or, d’après
mon expérience, la plupart des scénarios
NAT ne fonctionnent pas.

Il existe un contournement : vous
pourriez peut-être éviter les problèmes
NAT en demandant à  l’Expert d’éditer le fichier .msrcincident reçu.
La ligne RCTICKET-ENCRYPTED= de
ce fichier contient une liste de toutes
les adresses IP présentes sur l’ordinateur
Novice quand l’invitation Remote
Assistance a été créée, dans le format
IP address:port (208.201.247.1:3389,
par exemple). En remplaçant les
adresses privées par l’adresse accessible
en externe du pare-feu NAT ou du
routeur NAT, vous devriez pouvoir faire
fonctionner Remote Assistance.

Pendant le développement de
Remote Assistance, Microsoft a pris en
compte les problèmes posés par NAT
et sa réponse a été de fournir le support
pour UPnP (Universal Plug and
Play). Pour faciliter les connexions dynamiques
entre des hôtes protégés par
NAT, UPnP permet la détection automatique
des unités de réseau et des attributions
d’adresses IP sur le LAN.
(Pour plus d’informations sur le standard
UPnP, allez à  l’UPnP Forum à 
http://www.upnp.org.) Dans le cas de
Remote Assistance, UPnP permet le
passage d’informations nécessaires à 
propos de la future connexion Remote
Assistance (le numéro de port TCP entrant
requis, l’adresse IP du système
Novice, la durée de la validité des requêtes,
par exemple) vers le routeur
validé UPnP.

Bien que UPnP résolve théoriquement
le problème des pare-feu et des
routeurs NAT, ce n’est pas un standard
très répandu. A l’heure qu’il est, une
poignée seulement de fabricants de routeurs et de pare-feu livrent des produits
qualifiés pour NAT qui supportent
UPnP. (La fonction Internet
Connection Sharing intégrée de XP et
les routeurs DI-714 et DI-804 de D-Link
Systems sont quelques exceptions qui
offrent le support UPnP.) Même si
d’autres fournisseurs offriront probablement
un tel support dans les prochains
mois, l’utilité de Remote
Assistance est actuellement limitée. On
ne peut que le regretter : aujourd’hui,
les LAN qualifiés pour NAT sont la
norme.