क्या यह संभव नहीं होना चाहिए? मान लें कि मुझे प्रतिक्रिया की आवश्यकता नहीं है, मैं सिर्फ एक अनुरोध भेजना चाहता हूं। क्या हमें tcp / ip हेडर को बदलने में सक्षम नहीं होना चाहिए, क्योंकि हमारा कंप्यूटर इसे भेजता है? मुझे शायद कुछ याद आ रहा है, बस वास्तव में जिज्ञासु है, इसके बारे में जानने के लिए।
जवाबों:
आप -H/--headerतर्क का उपयोग कर सकते हैं :
आप अपना आईपी पता खराब कर सकते हैं:
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"
आईपी पते के साथ ग्राहक बदल गया
$ 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:".
संदर्भ:
मुझे लगता है कि स्वीकृत जवाब वास्तव में आपके आईपी को खराब करने में मदद नहीं करेगा। जब तक आपके पास लक्ष्य मशीन के करीब राउटर तक पहुंच नहीं होती है तब तक आप अपने स्रोत आईपी को खराब नहीं कर सकते।
टीसीपी 3-वे हैंडशेक मैकेनिज्म पर काम करती है। आप इस हैंडशेक को पूरा नहीं कर पाएंगे क्योंकि टारगेट मशीन से हैंडशेक रिस्पॉन्स आपके स्पूफ़ किए गए आईपी पर जाएगा और आपका अपना नहीं (जब तक कि, जैसा कि पहले कहा गया था, आप उसके आस-पास के राउटर को नियंत्रित करते हैं और खुद के प्रति प्रतिक्रिया को पुनर्निर्देशित करते हैं)।
पुनश्च: आप एक यूडीपी संदेश भेजने में सक्षम हो सकते हैं, लेकिन मैंने इसकी कोशिश नहीं की है।
curl, इसलिए मैं मान रहा हूं कि वे कुछ HTTP संसाधन तक पहुंचने की कोशिश कर रहे हैं। UDP पर HTTP कुछ ऐसा नहीं है जो curlAFAIK का समर्थन करता है और न ही यह इस बिंदु पर प्रयोगात्मक से परे है।
यदि आपके स्थानीय नेटवर्क इंटरफ़ेस में कई IP पते हैं, तो स्रोत IP पते को बदलना संभव है।
मान लीजिए कि आपके पास एक सर्वर है जिसमें 2 आईपी पते हैं, 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
आप अपने वर्तमान सार्वजनिक आईपी पते को भयानक ifconfig.co वेब सेवा से सत्यापित कर सकते हैं :
$ curl -4 ifconfig.co
1.1.1.10
अन्य IP पते ( ) का उपयोग करके ifconfig.co वेब सेवा तक पहुँचने के लिए 2.2.2.20, आप लक्ष्य सर्वर के IP पते के आधार पर एक मार्ग बना सकते हैं। DNS Aरिकॉर्ड से लक्ष्य IP पते खोजने के लिए खुदाई का उपयोग करें :
$ 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 -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
नोट: यह केवल तभी काम करता है जब स्रोत आईपी पता आपके सर्वर पर हल किया जा सकता है, अन्यथा टीसीपी 3-रास्ता हैंडशेक विफल हो जाएगा, जैसा कि यहां बताया गया है ।