HTTP-запрос от PowerShell имеет неправильный удаленный IP


0

Я пытаюсь написать сценарий PowerShell, который выполняет HTTP-запрос. Запрос обрабатывается PHP-скриптом, который должен знать IP-адрес клиента. С этой целью он читает $_SERVER['REMOTE_ADDR'],

Теперь происходит следующее странное поведение:

  • Когда я использую такой сервис, как whatismyip.com, мой IP xxx.yyy.141.183
  • Когда я использую веб-браузер для вызова моего скрипта PHP, $_SERVER['REMOTE_ADDR'] возвращает тот же IP, что и выше, xxx.yyy.141.183 (как и ожидалось).
  • Когда я использую сценарий PowerShell для вызова того же самого сценария PHP, $_SERVER['REMOTE_ADDR'] возвращает другой IP, а именно xxx.yyy.51.111,

Сценарий PowerShell очень прост:

$wc = New-Object System.Net.WebClient
$wc.DownloadString("http://example.net/myscript.php")

Я наблюдаю, как это поведение связано с сетью моего университета. Поэтому я не знаю никаких подробностей о конфигурации сети. Я заметил, что разные машины, кажется, имеют разные IP-адреса, используя методы в пунктах 1 и 2, но все они имеют один и тот же IP-адрес, используя третий метод.

Вопрос: Как я могу изменить свой сценарий PowerShell так, чтобы он «вел себя как веб-браузер», то есть отправлял запрос, когда удаленный адрес, видимый сервером, равен удаленному адресу, который он видит при получении запроса от веб-браузера?

Бонусный вопрос: почему это происходит?


Откуда вызывается PHP? $_SERVER['REMOTE_ADDR'] относительно конечно .. и что делает ipconfig скажи твой IP есть? Скорее всего *.*.141.183 это брандмауэр вашего университета .. Но это всего лишь предположение.
Pogrindis

@Pogrindis Не уверен, что понимаю ваш вопрос. Я сижу перед своим ноутбуком, используя методы, указанные в пуле 1-3, за другим. Таким образом, все 3 звонка приходят от одного и того же клиента. ipconfig дает мне 141.183 как мой адрес IPv4.
CL.

Ну, не совсем, два других работают через сеть, которая будет иметь свои собственные правила роутера / брандмауэра и т. Д., Напрямую подключаясь к php (если он находится на вашем ноутбуке) с вашего PowerShell, не маршрутизируя за пределы вашей локальной машины.
Pogrindis

@Pogrindis Я думаю, что все запросы проходят через университетскую сеть (что еще?) И, наконец, все они определенно поступают на сервер (что я наблюдаю в лог-файлах). Чем отличаются запросы PowerShell?
CL.

Случайно ли это PowerShell Direct?
Pogrindis

Ответы:


0

Основываясь на обнаружении, что только Firefox делал запросы с правильным публичным IP xxx.yyy.141.183 в то время как IE и Chrome этого не сделали, я нашел следующее решение:

  • Тот факт, что разные браузеры ведут себя по-разному, означает, что проблема не связана напрямую с PowerShell, а связана с настройками прокси.
  • Я понял, что Firefox был настроен на «использование настроек прокси-сервера системы». Когда я изменил это на «автоматическое определение настроек прокси для сети» (грубый перевод, извините), Firefox (так же, как IE и Chrome) выдавал запросы с xxx.yyy.51.111 IP.
  • Исходя из этого, я пришел к выводу, что PowerShell должен использовать конфигурацию, которая позволяет ему автоматически определять параметры прокси. Эта гипотеза подтверждается документация :

Свойство Proxy идентифицирует экземпляр IWebProxy, который связывается с удаленными серверами от имени этого объекта WebClient. Прокси-сервер устанавливается системой с использованием файлов конфигурации и параметров локальной сети Internet Explorer. Чтобы указать, что прокси-сервер не должен использоваться, установите прокси-сервер. свойство экземпляра прокси, возвращенного методом GetEmptyWebProxy.

  • Как я не хочу менять конфигурацию системы и как GlobalProxySelection.GetEmptyWebProxy устарела, теперь я успешно использую предложенное решение Вот : Просто установите proxy собственность на null,

    $wc = New-Object System.Net.WebClient
    $wc.Proxy = $null
    $wc.DownloadString("http://example.net/myscript.php")
    
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.