Địa chỉ RFC 1918 trên internet mở?


18

Khi cố gắng chẩn đoán sự cố chuyển đổi dự phòng với tường lửa Cisco ASA 5520 của tôi, tôi đã chạy một traceroute đến www.btfl.com và, thật ngạc nhiên, một số bước nhảy đã trở lại dưới dạng địa chỉ RFC 1918.

Rõ ràng, máy chủ này không nằm sau tường lửa của tôi và không có VPN liên quan. Tôi phải kết nối qua mạng internet để đến đó.

Làm thế nào / tại sao điều này có thể?

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  *  *  *

và nó cũng làm điều tương tự từ kết nối FiOS của tôi ở nhà:

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.

Câu trả lời:


11

Cho phép các bộ định tuyến kết nối với nhau bằng RFC1918 hoặc các địa chỉ riêng khác, và trên thực tế, điều này rất phổ biến đối với những thứ như liên kết điểm-điểm và bất kỳ định tuyến nào diễn ra bên trong AS.

Chỉ các cổng biên trên mạng thực sự cần các địa chỉ IP có thể định tuyến công khai để định tuyến hoạt động. Nếu giao diện của bộ định tuyến không kết nối với bất kỳ AS nào khác (hoặc bất kỳ nhà cung cấp dịch vụ nào khác, đơn giản hơn), thì không cần quảng cáo tuyến trên internet và chỉ có thiết bị thuộc cùng một thực thể mới cần kết nối trực tiếp với giao diện.

Việc các gói trả về cho bạn theo cách này trong traceroute là vi phạm nhẹ RFC1918, nhưng thực sự không cần thiết phải sử dụng NAT cho các thiết bị này vì chúng không kết nối với những thứ tùy ý trên internet; họ chỉ đi dọc theo giao thông

Việc lưu lượng truy cập tuyến đường (có thể có mạch) thông qua một số tổ chức mà nó thực hiện chỉ là hậu quả của hoạt động của các giao thức định tuyến cổng bên ngoài. Có vẻ như hoàn toàn hợp lý khi Microsoft có một số xương sống và một số người đã quan tâm đến nó; bạn không phải là một ISP bán buôn để định tuyến lưu lượng.

Lưu lượng truy cập đã đi qua nhiều loạt bộ định tuyến có IP riêng, chuyển qua các bộ định tuyến có IP công cộng ở giữa, không có gì lạ - nó chỉ đơn giản chỉ ra (trong trường hợp này) hai mạng khác nhau dọc theo đường dẫn đã định tuyến lưu lượng qua bộ định tuyến của chúng mà họ đã chọn để đánh số theo cách này.


16

Không chỉ RFC 1918 ... mà còn RFC 6598 , tức là 100.64.0.0/10không gian CGN. Cả hai đều là mạng riêng, nhưng sau này được chuẩn hóa gần đây và ít được biết đến hơn.

Điều này không phải là bất thường từ quan điểm theo dõi. Bạn không thực sự nói chuyện trực tiếp với các máy chủ 10space và 100space đó, bạn đang gửi các gói có TTL lớn hơn tới bộ định tuyến bước nhảy tiếp theo của bạn. Để giữ cho câu trả lời không bị quá dài, liên kết Wikipedia này tóm tắt quá trình.

Có gì không bình thường là rằng gói này đi qua không gian IP công cộng, và sau đó được tạo đường hầm qua không gian IP riêng để đạt được một "công cộng" net một lần nữa. 157.56.176.94được sở hữu bởi Microsoft và gói đi qua các mạng do MS sở hữu trước khi truy cập mạng riêng ... vì vậy, đó đơn giản là những gì Microsoft đang chọn thực hiện với không gian mạng của họ ở cả hai đầu của không gian riêng. Họ quảng cáo các tuyến đường; các bộ định tuyến khác chỉ làm những gì họ nói.

Theo nguyên tắc chung, không, các nhà khai thác mạng thường không phơi bày mạng riêng của họ dọc theo tuyến đến không gian IP công cộng từ bên ngoài mạng của họ. Đó là lý do tại sao điều này rất khác thường.

(đó có thể là một tuyến đường bị mất ở đâu đó trên biên giới của họ, khiến các gói đi qua một con đường không tối ưu cuối cùng đến đích, nhưng tôi không phải là một người kết nối mạng và ai đó có thể có thể đâm tốt hơn vào nó)


1
Hầu hết các triển khai theo dõi dựa trên UDP + ICMP khi bài viết của bạn tiếp tục.
dmourati

@dmourati Là một quản trị viên Unix, tôi buộc phải đỏ mặt. Tât nhiên. Cảm ơn bạn.
Andrew B

Theo kinh nghiệm của tôi, điều này không có gì bất thường cả. Nhiều nhà mạng sử dụng 10.0.0.0/8 trong mạng của họ và để lộ số lượng đáng lo ngại của mạng.
Paul Gear
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.