열린 인터넷에서 RFC 1918 주소?

Cisco ASA 5520 방화벽으로 페일 오버 문제를 진단하기 위해 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.

라우터가 RFC1918 또는 다른 개인 주소를 사용하여 서로 연결하는 것이 허용되며, 실제로는 지점 간 링크 및 AS 내부에서 발생하는 라우팅과 같은 경우에 매우 일반적입니다.

라우팅이 작동하려면 네트워크의 경계 게이트웨이 만 실제로 공개적으로 라우팅 가능한 IP 주소가 필요합니다. 라우터의 인터페이스가 다른 AS (또는 다른 서비스 제공 업체, 더 간단히 말해서)에 연결되지 않으면 인터넷에서 경로를 광고 할 필요가 없으며 동일한 엔티티에 속하는 장비 만 직접 연결해야합니다. 상호 작용.

패킷이 traceroute에서 이러한 방식으로 반환되는 것은 RFC1918을 약간 위반 한 것이지만 인터넷 자체의 임의의 항목에 연결되지 않으므로 이러한 장치에 NAT를 사용할 필요는 없습니다. 그들은 단지 교통을 통과합니다.

트래픽이 여러 조직을 통해 (아마도 회로적인) 경로를 사용한다는 것은 외부 게이트웨이 라우팅 프로토콜의 작동 결과 일뿐입니다. Microsoft에 백본이 있고 일부 사람들이 이에 대해 조사한 것은 완벽하게 합리적입니다. 트래픽을 라우팅하기 위해 도매 ISP가 될 필요는 없습니다.

트래픽이 개인 IP를 가진 여러 시리즈의 라우터를 통과하고 그 사이에 퍼블릭 IP를 가진 라우터를 통과하는 것은 특히 이상하지 않습니다. 경로를 따라 두 개의 서로 다른 네트워크가 자신의 라우터를 통해 트래픽을 라우팅했음을 나타냅니다. 그들은 이런 식으로 번호를 선택했습니다.

RFC 1918뿐만 아니라 RFC 6598 , 즉 100.64.0.0/10CGN 공간 도 아닙니다 . 둘 다 개인 네트워크이지만 후자는 더 표준화되어 있고 알려지지 않았습니다.

이것은 traceroute 관점에서 드문 일이 아닙니다. 실제로 10space 및 100space 호스트와 직접 대화하는 것이 아니라 점차 큰 TTL이있는 패킷을 다음 홉 라우터로 보냅니다. 답변이 너무 길어지지 않도록 이 Wikipedia 링크 는 프로세스를 요약합니다.

무엇 이며 특이한 것은이 패킷 공용 IP 공간을 통과 한 다음 또 다시 "공개"그물에 도달하기 위해 개인 IP 공간을 통해 터널링되는 것입니다. 157.56.176.94Microsoft가 소유하고 있으며 패킷은 개인 네트워크에 도달하기 전에 MS 소유 네트워크를 통과합니다. 그래서 Microsoft는 개인 공간의 양쪽 끝에서 네트워크 공간과 관련하여 선택하는 것입니다. 그들은 노선을 광고합니다. 다른 라우터는 단지 그들이 말한 것을 수행합니다.

일반적으로 네트워크 운영자는 일반적으로 네트워크 외부에서 공용 IP 공간으로의 경로를 따라 개인 네트워크를 노출시키지 않습니다. 이것이 이례적인 이유입니다.

(경계 어딘가에 경로가 누락되어 패킷이 최종 목적지에 도달하는 최적이 아닌 경로를 통과하게 만들 수 있지만 네트워킹 담당자가 아니므로 누군가 더 잘 찌를 수 있습니다)