Պրոքսիի հավատարմագրերը PowerShell-ի երկրորդ թռիչքին

Տրամադրեք նախատեսված պրոքսի հաշիվը հեռավոր սերվերում աշխատող Invoke-WebRequest-ին՝ փոխարենը ենթադրելու, որ remoting մուտքը պատվիրակված է։

Վեբ հարցումը, որը B սերվերի վրա աշխատում է ինտերակտիվ, կարող է ստանալ 407, երբ նույն հրամանը այնտեղ գործարկվում է PowerShell remoting-ով։ A-ից B մուտքը ավտոմատ չի պատվիրակում այդ ինքնությունը B-ի հաջորդ նույնականացման փոխանակման համար։

A → remoting session on B → HTTP proxy → website

Աջակցվող մոտեցումներից մեկն այն է, որ պրոքսի հաշիվը բացահայտ տրամադրվի ելքային հարցման համար։ Գոյություն ունեցող PSSession-ով և պատշաճ ձեռք բերված PSCredential օբյեկտով՝

Invoke-Command -Session $session -ArgumentList $proxyCredential -ScriptBlock {
    param([pscredential]$outboundProxyCredential)

    $requestOptions = @{
        Uri = 'https://api.example/'
        Proxy = 'http://proxy.example:8080'
        ProxyCredential = $outboundProxyCredential
    }
    Invoke-WebRequest @requestOptions
}

Հավատարմագրի օբյեկտը նախատեսված է պրոքսիի համար։ Սեսիան դեռ օգտագործում է իր սովորական remoting նույնականացումը, և ցանկացած կայք մուտքը մնում է այդ կայքի հարցման մաս։

Սա խուսափում է առաջին մուտքի ավտոմատ պատվիրակման վրա հենվելուց։ Սակայն պահանջում է, որ հեռավոր հոսթը տրամադրված հաշվի նյութը մշակի որպես նախատեսված կառավարման ձևավորման մաս։ Այլ ճարտարապետություններ, օրինակ կառավարվող RunAs վերջնակետը կամ սահմանափակ ծառայության հասանելիությունը, ունեն իրենց կարգավորման պահանջները։

Եթե սխալ ենթադրությունը լռելյայն պրոքսի հավատարմագրերն էին, գրանցեք այն հաշիվը, որի ներքո գործարկվում է հեռավոր հրամանը, և այն նույնականացումը, որը պահանջում է պրոքսին։ Ավելի երկար վեբ հարցման ժամկետը չի կարող տրամադրել բացակայող հավատարմագրեր։

New-PSSessionOption-ի պրոքսի ընտրանքները վերաբերում են հենց remoting կապին։ Կարգավորեք Invoke-WebRequest-ը հեռավոր սկրիպտի բլոկի ներսում, երբ հենց B-ի արտաքին վեբ կապն է պրոքսի կարիք ունենում։

Առնչվող հոդվածներ