खुले इंटरनेट पर RFC 1918 का पता?

Question

मेरे सिस्को एएसए 5520 फायरवॉल के साथ एक असफल समस्या का निदान करने की कोशिश में, मैंने www.btfl.com के लिए एक ट्रेसरूट चलाया और, मेरे आश्चर्य के लिए, कुछ हॉप्स आरएफसी 1918 के पते के रूप में वापस आए।

बस स्पष्ट होने के लिए, यह होस्ट मेरे फ़ायरवॉल के पीछे नहीं है और इसमें कोई वीपीएन शामिल नहीं है। मुझे वहां पहुंचने के लिए खुले इंटरनेट से जुड़ना होगा।

यह कैसे / क्यों संभव है?

asa# traceroute www.btfl.com

Tracing the route to 157.56.176.94

 1  <redacted>
 2  <redacted>
 3  <redacted>
 4  <redacted>
 5  nap-edge-04.inet.qwest.net (67.14.29.170) 0 msec 10 msec 10 msec
 6  65.122.166.30 0 msec 0 msec 10 msec
 7  207.46.34.23 10 msec 0 msec 10 msec
 8   *  *  *
 9  207.46.37.235 30 msec 30 msec 50 msec
 10 10.22.112.221 30 msec
    10.22.112.219 30 msec
    10.22.112.223 30 msec
 11 10.175.9.193 30 msec 30 msec
    10.175.9.67 30 msec
 12 100.94.68.79 40 msec
    100.94.70.79 30 msec
    100.94.71.73 30 msec
 13 100.94.80.39 30 msec
    100.94.80.205 40 msec
    100.94.80.137 40 msec
 14 10.215.80.2 30 msec
    10.215.68.16 30 msec
    10.175.244.2 30 msec
 15  *  *  *
 16  *  *  *
 17  *  *  *

और यह घर पर मेरे FiOS कनेक्शन से एक ही काम करता है:

C:\>tracert www.btfl.com

Tracing route to www.btfl.com [157.56.176.94]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  myrouter.home [192.168.1.1]
  2     8 ms     7 ms     8 ms  <redacted>
  3    10 ms    13 ms    11 ms  <redacted>
  4    12 ms    10 ms    10 ms  ae2-0.TPA01-BB-RTR2.verizon-gni.net [130.81.199.82]
  5    16 ms    16 ms    15 ms  0.ae4.XL2.MIA19.ALTER.NET [152.63.8.117]
  6    14 ms    16 ms    16 ms  0.xe-11-0-0.GW1.MIA19.ALTER.NET [152.63.85.94]
  7    19 ms    16 ms    16 ms  microsoft-gw.customer.alter.net [63.65.188.170]
  8    27 ms    33 ms     *     ge-5-3-0-0.ash-64cb-1a.ntwk.msn.net [207.46.46.177]
  9     *        *        *     Request timed out.
 10    44 ms    43 ms    43 ms  207.46.37.235
 11    42 ms    41 ms    40 ms  10.22.112.225
 12    42 ms    43 ms    43 ms  10.175.9.1
 13    42 ms    41 ms    42 ms  100.94.68.79
 14    40 ms    40 ms    41 ms  100.94.80.193
 15     *        *        *     Request timed out.

Answer 1

RFC1918 या अन्य निजी पतों का उपयोग करते हुए राउटर को एक-दूसरे से कनेक्ट करना अनुमत है, और वास्तव में यह पॉइंट-टू-पॉइंट लिंक, और किसी भी राउटिंग जो कि एक एएस के अंदर होता है, के लिए बहुत आम है।

नेटवर्क पर केवल बॉर्डर गेटवे वास्तव में काम करने के लिए रूटिंग के लिए सार्वजनिक रूप से निष्क्रिय आईपी पते की आवश्यकता होती है। यदि राउटर का इंटरफ़ेस किसी अन्य एसेस (या किसी अन्य सेवा प्रदाता, अधिक सरलता से) से कनेक्ट नहीं होता है, तो इंटरनेट पर मार्ग का विज्ञापन करने की कोई आवश्यकता नहीं है, और केवल एक ही इकाई से संबंधित उपकरणों को सीधे कनेक्ट करने की आवश्यकता होगी इंटरफेस।

कि पैकेट ट्रेसरआउट में इस तरह से आपके पास लौटते हैं, RFC1918 का एक मामूली उल्लंघन है, लेकिन इन उपकरणों के लिए NAT का उपयोग करना वास्तव में आवश्यक नहीं है क्योंकि वे स्वयं इंटरनेट पर मनमानी चीजों से कनेक्ट नहीं होते हैं; वे बस यातायात के साथ गुजरते हैं।

यह ट्रैफ़िक कई संगठनों के माध्यम से (संभवतः सर्किटस) मार्ग लेता है जो यह करता है कि यह बाहरी गेटवे मार्ग प्रोटोकॉल के संचालन का एक परिणाम है। यह पूरी तरह से उचित लगता है कि Microsoft की कुछ रीढ़ है और कुछ लोगों ने इसके साथ सहानुभूति जताई है; मार्ग यातायात के लिए आपको थोक ISP होना आवश्यक नहीं है।

निजी आईपी के साथ राउटर की कई श्रृंखलाओं के माध्यम से यातायात चला गया है, बीच में सार्वजनिक आईपी के साथ लोगों के माध्यम से स्थानांतरित करना, विशेष रूप से अजीब नहीं है - यह बस इंगित करता है (इस मामले में) पथ के साथ दो अलग-अलग नेटवर्क ने अपने स्वयं के राउटर के माध्यम से यातायात को रूट किया है जिसे उन्होंने इस तरह से संख्या के लिए चुना है।

Answer 2

सिर्फ RFC 1918 ही नहीं ... RFC 6598 यानी 100.64.0.0/10CGN स्पेस भी। वे दोनों निजी नेटवर्क हैं, लेकिन उत्तरार्द्ध हाल ही में मानकीकृत है और कम ज्ञात है।

यह एक अनुरेखक दृष्टिकोण से असामान्य नहीं है। आप वास्तव में उन 10स्पेस और 100स्पेस होस्ट से सीधे बात नहीं कर रहे हैं, आप अपने अगले हॉप राउटर के लिए बड़े पैमाने पर TTLs के साथ पैकेट भेज रहे हैं। उत्तर को लंबे समय तक प्राप्त करने से रोकने के लिए, यह विकिपीडिया लिंक प्रक्रिया को सारांशित करता है।

क्या है असामान्य है कि यह पैकेट सार्वजनिक आईपी अंतरिक्ष को पार करता है, और फिर एक बार फिर एक "सार्वजनिक" शुद्ध तक पहुँचने के लिए निजी IP अंतरिक्ष के माध्यम से टनल जाता है। 157.56.176.94Microsoft के स्वामित्व में है, और पैकेट निजी स्वामित्व को हिट करने से पहले MS के स्वामित्व वाले नेटवर्क का पता लगाता है ... इसलिए Microsoft बस निजी स्थान के दोनों सिरों पर अपने नेटवर्क स्थान के साथ क्या करना चाहता है। वे मार्गों का विज्ञापन करते हैं; अन्य राउटर वही करते हैं जो उन्हें बताया जाता है।

एक सामान्य नियम के रूप में, नहीं, नेटवर्क ऑपरेटर आमतौर पर अपने नेटवर्क के बाहर से सार्वजनिक आईपी स्थान के लिए एक मार्ग के साथ अपने निजी जाल को उजागर नहीं करते हैं। इसलिए यह इतना असामान्य है।

(यह उनकी सीमा पर कहीं गुम मार्ग हो सकता है, जिससे पैकेट एक गैर-इष्टतम पथ को पार कर सकता है जो अंततः अपने गंतव्य तक पहुंचता है, लेकिन मैं एक नेटवर्किंग लड़का नहीं हूं और कोई शायद इस पर एक बेहतर छुरा ले सकता है)

Comments

जैसा कि आपका लेख राज्य में चलता है, अधिकांश ट्रेसरआउट कार्यान्वयन UDP + ICMP पर निर्भर करते हैं।

— dmourati

@Mourati एक यूनिक्स व्यवस्थापक के रूप में, मैं ब्लश करने के लिए मजबूर हूं। ओह। धन्यवाद।

— एंड्रयू बी

मेरे अनुभव में, यह बिल्कुल भी असामान्य नहीं है। कई वाहक अपने नेटवर्क के अंदर 10.0.0.0/8 का उपयोग करते हैं, और इसकी गड़बड़ी को उजागर करते हैं।

— पॉल गियर