ที่อยู่ RFC 1918 บนอินเทอร์เน็ตเปิด?


18

ในการพยายามวินิจฉัยปัญหาความล้มเหลวด้วยไฟร์วอลล์ Cisco ASA 5520 ของฉันฉันใช้ traceroute ไปที่ www.btfl.com และทำให้ฉันประหลาดใจมากกระโดดขึ้นมาบางส่วนจากที่อยู่ RFC 1918

เพื่อให้ชัดเจนโฮสต์นี้ไม่ได้อยู่หลังไฟร์วอลล์ของฉันและไม่มี VPN ที่เกี่ยวข้อง ฉันต้องเชื่อมต่อผ่านอินเทอร์เน็ตเพื่อไปที่นั่น

เป็นไปได้อย่างไร / ทำไมเป็นไปได้?

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.

คำตอบ:


11

อนุญาตให้เราเตอร์เชื่อมต่อกันโดยใช้ RFC1918 หรือที่อยู่ส่วนตัวอื่น ๆ และในความเป็นจริงสิ่งนี้เป็นเรื่องธรรมดามากสำหรับสิ่งต่างๆเช่นการเชื่อมต่อแบบจุดต่อจุดและการกำหนดเส้นทางใด ๆ ที่เกิดขึ้นภายใน AS

เฉพาะเกตเวย์ชายแดนบนเครือข่ายเท่านั้นที่จำเป็นต้องมีที่อยู่ IP ที่กำหนดเส้นทางได้สาธารณะเพื่อการกำหนดเส้นทางให้ทำงาน หากอินเทอร์เฟซของเราเตอร์ไม่ได้เชื่อมต่อกับ ASes อื่น ๆ (หรือผู้ให้บริการอื่น ๆ ได้ง่ายกว่า) ไม่จำเป็นต้องโฆษณาเส้นทางบนอินเทอร์เน็ตและอุปกรณ์ที่เป็นของนิติบุคคลเดียวกันเท่านั้นจะต้องเชื่อมต่อโดยตรงกับ อินเตอร์เฟซ.

การที่แพ็กเก็ตกลับมาหาคุณด้วยวิธีนี้ใน traceroute เป็นการละเมิด RFC1918 เล็กน้อย แต่จริงๆแล้วมันไม่จำเป็นที่จะต้องใช้ NAT สำหรับอุปกรณ์เหล่านี้เนื่องจากพวกเขาไม่ได้เชื่อมต่อกับสิ่งต่าง ๆ บนอินเทอร์เน็ตเอง พวกเขาแค่ผ่านไปตามการจราจร

การรับส่งข้อมูลจะใช้เส้นทาง (อาจเป็นวงรอบ) ผ่านหลายองค์กรที่เป็นเพียงผลมาจากการดำเนินการของโปรโตคอลการกำหนดเส้นทางเกตเวย์ภายนอก ดูเหมือนว่าเหมาะสมอย่างยิ่งที่ Microsoft มีกระดูกสันหลังและบางคนได้เห็นด้วย คุณไม่จำเป็นต้องเป็นผู้ให้บริการอินเทอร์เน็ตรายใหญ่ในการกำหนดเส้นทางการจราจร

การรับส่งข้อมูลผ่านเราเตอร์หลายชุดที่มี IP ส่วนตัวการส่งผ่านที่มี IP สาธารณะในระหว่างนั้นไม่แปลกโดยเฉพาะ - มันบ่งบอก (ในกรณีนี้) สองเครือข่ายที่แตกต่างกันตามเส้นทางได้ส่งทราฟฟิกผ่านเราเตอร์ของตนเอง ซึ่งพวกเขาเลือกที่จะกำหนดหมายเลขด้วยวิธีนี้


16

ไม่ใช่เพียง RFC 1918 ... เช่นกันกับRFC 6598เช่น100.64.0.0/10พื้นที่ CGN ทั้งสองเป็นเครือข่ายส่วนตัว แต่หลังเป็นมาตรฐานล่าสุดและเป็นที่รู้จักน้อย

นี่ไม่ใช่เรื่องแปลกจากมุมมองของผู้ติดตาม คุณไม่ได้พูดคุยกับโฮสต์ 10space และ 100space เหล่านั้นโดยตรงคุณกำลังส่งแพ็กเก็ตที่มี TTLs ที่ใหญ่ขึ้นเรื่อย ๆ ไปยังเราเตอร์ hop ของคุณต่อไป เพื่อไม่ให้คำตอบยาวเกินไปลิงค์ Wikipedia นี้สรุปกระบวนการ

อะไรคือผิดปกติที่แพ็คเก็ตนี้ลัดเลาะพื้นที่ IP สาธารณะและมีการเจาะแล้วผ่านพื้นที่ IP เอกชนในการเข้าถึงสุทธิ "สาธารณะ" อีกครั้ง 157.56.176.94เป็นเจ้าของโดย Microsoft และแพ็คเก็ตลัดเลาะเครือข่ายของ MS ก่อนที่จะไปถึง net ส่วนตัว ... ดังนั้นมันเป็นเพียงสิ่งที่ Microsoft เลือกที่จะทำกับพื้นที่เครือข่ายของพวกเขาที่ปลายทั้งสองของพื้นที่ส่วนตัว พวกเขาโฆษณาเส้นทาง เราเตอร์อื่นเพียงทำในสิ่งที่พวกเขาบอก

ตามกฎทั่วไปแล้วไม่มีผู้ให้บริการเครือข่ายโดยทั่วไปจะไม่เปิดเผยตาข่ายส่วนตัวตามเส้นทางไปยังพื้นที่ IP สาธารณะจากภายนอกเครือข่าย นั่นเป็นสาเหตุที่ผิดปกติมาก

(อาจเป็นเส้นทางที่หายไปที่ไหนสักแห่งบนชายแดนทำให้แพ็คเก็ตไปสำรวจเส้นทางที่ไม่เหมาะสมซึ่งในที่สุดก็มาถึงปลายทางของมัน แต่ฉันไม่ใช่คนเครือข่ายและใครบางคนอาจแทงได้ดีกว่า)


1
การใช้งาน traceroute ส่วนใหญ่ใช้ UDP + ICMP เป็นบทความของคุณ
dmourati

@dmourati ในฐานะผู้ดูแลระบบ Unix ฉันถูกบังคับให้ต้องอาย ดุจ ขอขอบคุณ.
Andrew B

จากประสบการณ์ของฉันมันไม่ได้ผิดปกติเลย ผู้ให้บริการจำนวนมากใช้ 10.0.0.0/8 ภายในเครือข่ายของพวกเขาและเปิดเผยจำนวนรบกวน
พอลเกียร์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.