Vitambulisho vya proksi kwenye hatua ya pili ya PowerShell
Toa akaunti ya proksi inayokusudiwa kwa Invoke-WebRequest inayofanya kazi kwenye seva ya mbali badala ya kudhani kuwa kuingia kwa remoting kunapewa.
Ombi la wavuti linalofanya kazi kwa mwingiliano kwenye seva B linaweza kupokea 407 wakati amri hiyo hiyo inatekelezwa hapo kupitia PowerShell remoting. Kuingia kutoka A hadi B hakupeana kitambulisho hicho kiotomatiki kwa mabadilishano ya uthibitishaji yajayo ya B.
A → remoting session on B → HTTP proxy → website
Muundo mmoja unaotumika ni kutoa akaunti ya proksi waziwazi kwa ombi la kutoka. Ukiwa na PSSession iliyopo na kitu cha PSCredential kilichopatikana ipasavyo:
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
}
Kitu cha vitambulisho ni cha akaunti inayokusudiwa ya proksi. Kipindi bado kinatumia uthibitishaji wake wa kawaida wa remoting, na kuingia kokote kwenye tovuti kunabaki kuwa sehemu ya ombi la tovuti hiyo.
Hii inaepuka kutegemea upokezaji wa kiotomatiki wa kuingia kwa mara ya kwanza. Hata hivyo inahitaji mwenyeji wa mbali kushughulikia nyenzo za akaunti zilizotolewa kama sehemu ya muundo unaokusudiwa wa usimamizi. Miundo mingine, kama sehemu ya mwisho ya RunAs inayosimamiwa au ufikiaji mdogo wa huduma, ina mahitaji yake ya usanidi.
Ikiwa vitambulisho vya proksi vya chaguo-msingi vilikuwa dhana isiyo sahihi, rekodi akaunti ambayo amri ya mbali inafanya kazi chini yake na uthibitishaji ambao proksi inaomba. Muda mrefu zaidi wa ombi la wavuti hauwezi kutoa vitambulisho vinavyokosekana.
Chaguo za proksi kwenye New-PSSessionOption zinahusu muunganisho wa remoting wenyewe. Sanidi Invoke-WebRequest ndani ya kizuizi cha skripti cha mbali wakati muunganisho wa wavuti wa nje wa B ndio unaohitaji proksi.