Comment résoudre les problèmes d’accès proxy PowerShell lorsqu’on est derrière un réseau d’entreprise
Utiliser PowerShell derrière un proxy d’entreprise ? Oui, c’est parfois un vrai casse-tête. Vous pouvez vous retrouver à exécuter des commandes Update-Helpet Invoke-WebRequestà recevoir des messages d’erreur indiquant une impossibilité de connexion. En effet, PowerShell, et notamment l’ancienne version Windows PowerShell 5.1, n’utilise pas automatiquement les paramètres proxy de votre système pour les requêtes web. C’est un problème majeur si vous avez l’habitude d’exécuter des commandes sans problème. Ce souci se produit généralement sur un réseau protégé qui achemine le trafic internet via un serveur proxy, souvent avec authentification. Configurer PowerShell pour qu’il communique via ce proxy est tout à fait possible, mais cela nécessite une configuration manuelle, car, comme toujours, Windows complique inutilement les choses. Vous obtiendrez des erreurs du type « Impossible de se connecter au serveur distant », ou, avec les commandes de mise à jour, un message indiquant que le contenu est indisponible ou que la source du package est introuvable. Pas très convivial. Bonne nouvelle : il existe plusieurs façons de configurer PowerShell pour qu’il achemine correctement les requêtes Internet via votre proxy, que vous utilisiez PowerShell classique (5.1) ou PowerShell Core (6+).Nous allons passer en revue les principales méthodes : la configuration du proxy WinHTTP, la gestion de l’authentification et l’enregistrement de cette configuration dans votre profil, afin de ne pas avoir à la refaire à chaque session.
Comment résoudre les problèmes d’accès proxy dans PowerShell
Configurer les paramètres du proxy WinHTTP — PowerShell utilise cette configuration par défaut pour de nombreuses tâches.
Voici la première chose à vérifier. PowerShell utilise les paramètres WinHTTP en interne, qui sont distincts de ceux de votre navigateur ou des paramètres proxy d’Internet Explorer. Pour vérifier la configuration actuelle, ouvrez PowerShell et exécutez la commande suivante : netsh winhttp show proxy Si le message « Accès direct (aucun serveur proxy) » s’affiche, PowerShell n’est pas encore configuré pour passer par votre proxy. Sur certaines configurations, il hérite même des paramètres d’IE si vous les importez : netsh winhttp import proxy source=ie Cela suffit généralement si votre entreprise a déjà configuré votre PC pour utiliser les paramètres proxy d’IE. Sinon, ou si cela ne fonctionne pas, vous pouvez configurer votre proxy manuellement : netsh winhttp set proxy "192.168.0.14:3128" Remplacez l’adresse IP et le port par l’adresse de votre proxy. Vous pouvez également ajouter une liste d’exclusion pour que les adresses locales ou les sites internes ne soient pas acheminés via le proxy : netsh winhttp set proxy "192.168.0.14:3128" bypass-list="10.*, 172.*, 192.168.*, *.corp.domain" Une fois la configuration terminée, vérifiez à nouveau netsh winhttp show proxy. Vous indiquez ainsi à Windows d’acheminer les requêtes web sortantes via ce proxy. Cela fonctionne, mais si votre proxy requiert une authentification, c’est là que les erreurs surviennent.
Gestion de l’authentification du proxy — Le client Web par défaut ignore vos informations d’identification de proxy.
Voici le problème : les classes de requêtes web classiques de PowerShell (surtout les plus anciennes) n’envoient pas automatiquement les informations d’identification de l’utilisateur connecté au proxy. C’est pourquoi les commandes échouent avec des erreurs telles que « 407 Authentification proxy requise » ou similaires. Pour résoudre ce problème, vous devez spécifier explicitement vos informations d’identification : – Si vous utilisez un compte de domaine et que votre proxy prend en charge l’authentification Active Directory (NTLM ou Kerberos), vous pouvez réutiliser vos informations d’identification actuelles : $Wcl = New-Object System. Net. WebClient $Wcl. Headers. Add("user-agent", "PowerShell Script") $Wcl. Proxy. Credentials = [System. Net. CredentialCache]::DefaultNetworkCredentials PowerShell utilise alors vos informations de connexion actuelles, sans invite de mot de passe. Cependant, il arrive que cela ne fonctionne pas ou que votre proxy exige des informations d’identification explicites. Pour une saisie manuelle, exécutez : $Wcl = New-Object System. Net. WebClient $Creds = Get-Credential $Wcl. Proxy. Credentials = $Creds Une invite de connexion s’affichera. Une fois ces informations définies, les commandes comme `sudo` Invoke-WebRequestou ` Update-Helpsudo` devraient réussir, à condition que le proxy accepte ces informations d’identification. Pour PowerShell Core (6+), la procédure est légèrement différente : il utilise la classe HttpClient, dont la configuration est différente. [System. Net. Http. HttpClient]::DefaultProxy = New-Object System. Net. WebProxy('http://proxyserver:3128') [System. Net. Http. HttpClient]::DefaultProxy. Credentials = [System. Net. CredentialCache]::DefaultCredentials Vous pouvez également configurer le système pour qu’il demande les informations d’identification de manière interactive. [System. Net. Http. HttpClient]::DefaultProxy. Credentials = Get-Credential Remarque : dans de nombreux cas, la définition globale de DefaultProxy est très utile, mais il est parfois nécessaire de spécifier le proxy pour chaque requête.
Conservez les paramètres de proxy dans votre profil PowerShell — Vous n’aurez ainsi pas à les configurer à chaque fois.
Configurer manuellement les proxys à chaque session devient vite fastidieux. Pour automatiser le processus, ajoutez ces commandes à votre script de profil PowerShell. Exécutez simplement : notepad $PROFILE ou, si vous configurez tous les utilisateurs, notepad $PROFILE. AllUsersCurrentHost collez ici vos commandes de configuration de proxy, comme la configuration de WebRequest ou WebProxy avec des informations d’identification. Avant d’exécuter les scripts, vous devrez peut-être définir votre stratégie d’exécution : Set-ExecutionPolicy RemoteSigned Après avoir enregistré, redémarrez PowerShell ; la configuration du proxy se chargera automatiquement. C’est très pratique si vous travaillez fréquemment derrière le proxy de votre entreprise et que vous n’aimez pas refaire la configuration.
Vérification de la configuration du proxy — Comment voir les paramètres actuels
Vous souhaitez vérifier si vos paramètres de proxy sont actifs ? Utilisez : Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyServer, ProxyEnable Si ProxyEnable vaut 1, le proxy est activé. L’adresse du proxy doit se trouver dans ProxyServer. Pour vérifier que votre système achemine bien le trafic via le bon proxy, effectuez le test suivant : [System. Net. WebProxy]::GetDefaultProxy() Et pour activer ou désactiver facilement le proxy : Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable -Value 1 ou Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable -Value 0 Attention : la modification de ces paramètres peut affecter d’autres applications. Ne le faites donc que si vous êtes à l’aise avec ce risque.
Modifier les paramètres de proxy sous Windows avec PowerShell — Parce que parfois, vous avez besoin d’une configuration dynamique
Vous souhaitez configurer un nouveau proxy directement ? Utilisez une fonction comme celle-ci : function Set-Proxy($server, $port) { if ((Test-NetConnection -ComputerName $server -Port $port).TcpTestSucceeded) { Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyServer -Value "$($server):$($port)" Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyEnable -Value 1 } else { Write-Error "Proxy server or port invalid: $($server):$($port)" } } Appelez-la ainsi : Set-Proxy 192.168.1.100 3128 Vous pouvez également ajouter des adresses d’exception de proxy avec : $ProxyExceptionList = ";*.woshub.com;*.contoso.com" $ProxyProperty = Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" if ($ProxyProperty. ProxyOverride) { $OldValue = $ProxyProperty. ProxyOverride $NewValue = $OldValue + $ProxyExceptionList Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name ProxyOverride -Value $NewValue } else { Write-Warning "Proxy override list is empty!" } Et si vous souhaitez stocker votre nom d’utilisateur et votre mot de passe de proxy (ce qui n’est *pas* très sécurisé), vous pouvez les enregistrer dans le registre : Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyUser -Value "username" Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyPass -Value "password" —
Conclure
Configurer PowerShell pour qu’il fonctionne correctement derrière un proxy d’entreprise n’est pas une mince affaire, mais avec un peu de configuration manuelle, c’est faisable. L’essentiel est de comprendre que PowerShell utilise les configurations de proxy Windows ou WinHTTP, et non celles de votre navigateur. Configurer le proxy globalement, gérer correctement les informations d’identification et, éventuellement, enregistrer les configurations dans votre profil vous évitera bien des tracas par la suite. Parfois, Windows semble compliquer inutilement les choses, mais ces astuces permettent généralement d’obtenir une configuration fonctionnelle.
- Vérifiez les paramètres de proxy actuels avec
netsh winhttp show proxy. - Configurez-le avec
netsh winhttp set proxy. - Gérez les informations d’identification via des commandes PowerShell, notamment si une authentification par proxy est impliquée.
- Pour plus de commodité, enregistrez vos paramètres favoris dans votre profil PowerShell.
- Utilisez des commandes de test comme celle-ci
Test-NetConnectionpour vérifier la connectivité.
J’espère que cela permettra à ceux qui cherchent à configurer correctement leurs requêtes web de gagner quelques heures. N’oubliez pas qu’un redémarrage du système ou de la session est parfois nécessaire après avoir modifié la configuration du proxy. Bonne chance !