Разве это не возможно? Давайте предположим, что мне не нужен ответ, я просто хочу отправить запрос. Разве мы не должны иметь возможность изменять заголовки tcp / ip, потому что наш компьютер отправляет их? Я, наверное, что-то упускаю, просто очень любопытно, узнавая об этом в универе.
Ответы:
Вы можете использовать -H/--headerаргумент:
Вы можете подделать свой IP-адрес:
curl --header "X-Forwarded-For: 192.168.0.2" http://example.com
Пример:
клиент
$ curl http://webhost.co.uk
веб-хостинг
$ tailf access.log | grep 192.168.0.54
192.168.0.54 - - [10/Nov/2014:15:56:09 +0000] "GET / HTTP/1.1" 200 14328 "-"
"curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3
libidn/1.18 libssh2/1.4.2"
клиент с измененным IP-адресом
$ curl --header "X-Forwarded-For: 192.168.0.99" http://webhost.co.uk
веб-хостинг
$ tailf access.log | grep 192.168.0.99
192.168.0.99 - - [10/Nov/2014:15:56:43 +0000] "GET / HTTP/1.1" 200
14328 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0
zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
локон
-H/--header <header>
(HTTP) Extra header to use when getting a web page. You may
specify any number of extra headers. Note that if you should add
a custom header that has the same name as one of the internal
ones curl would use, your externally set header will be used
instead of the internal one. This allows you to make even
trickier stuff than curl would normally do. You should not
replace internally set headers without knowing perfectly well
what you’re doing. Remove an internal header by giving a
replacement without content on the right side of the colon,
as in: -H "Host:".
Ссылки:
Я думаю, что принятый ответ не поможет вам полностью подделать ваш IP. Вы действительно не сможете подделать свой исходный IP, если у вас нет доступа к маршрутизаторам, расположенным рядом с целевой машиной.
TCP работает на 3-х стороннем механизме рукопожатия. Вы не сможете завершить это рукопожатие, так как ответ рукопожатия от целевой машины перейдет на ваш поддельный IP-адрес, а не на ваш собственный (если, как сказано выше, вы не контролируете его соседние маршрутизаторы и не перенаправляете ответ на себя).
PS: Вы можете отправить UDP-сообщение, но я не пробовал.
curl, я предполагаю, что они пытаются получить доступ к некоторому HTTP-ресурсу. HTTP over UDP не является чем-то, что curlподдерживает AFAIK, и не является чем-то за пределами экспериментального на данный момент.
Можно изменить исходный IP-адрес, если ваш локальный сетевой интерфейс имеет несколько IP-адресов.
Предположим, у вас есть сервер, который имеет 2 IP-адреса, 1.1.1.10и 2.2.2.20:
$ ip route
default via 1.1.1.193 dev eth0
1.1.1.192/27 via 1.1.1.193 dev eth0
1.1.1.192/27 dev eth0 proto kernel scope link src 1.1.1.10
2.2.2.20 via 2.2.2.20 dev eth0 scope link
Вы можете проверить свой текущий общедоступный IP-адрес с помощью потрясающего веб-сервиса ifconfig.co :
$ curl -4 ifconfig.co
1.1.1.10
Чтобы получить доступ к веб-службе ifconfig.co с помощью другого IP-адреса ( 2.2.2.20), вы можете создать маршрут на основе IP-адреса целевого сервера. Используйте dig, чтобы найти целевые IP-адреса из Aзаписей DNS :
$ dig ifconfig.co
...
ifconfig.co. 39 IN A 104.28.18.94
ifconfig.co. 39 IN A 104.28.19.94
...
Теперь добавьте пользовательские маршруты для этих IP-адресов:
$ ip route add 104.28.18.94/32 via 1.1.1.193 dev eth0 src 2.2.2.20
$ ip route add 104.28.19.94/32 via 1.1.1.193 dev eth0 src 2.2.2.20
Запустив curl снова, вы увидите, что используете другой IP-адрес источника:
$ curl -4 ifconfig.co
2.2.2.20
Кроме того, ваша информация о маршруте обновляется:
$ ip route
default via 1.1.1.193 dev eth0
1.1.1.192/27 via 1.1.1.193 dev eth0
1.1.1.192/27 dev eth0 proto kernel scope link src 1.1.1.10
2.2.2.20 via 2.2.2.20 dev eth0 scope link
104.28.18.94 via 1.1.1.193 dev eth0 src 2.2.2.20
104.28.19.94 via 1.1.1.193 dev eth0 src 2.2.2.20
Примечание: это работает только в том случае, если исходный IP-адрес может быть разрешен на вашем сервере, в противном случае трехстороннее рукопожатие TCP не будет выполнено, как указано здесь .