Adres RFC 1918 w otwartym Internecie?

Próbując zdiagnozować problem z przełączaniem awaryjnym w moich zaporach ogniowych Cisco ASA 5520, uruchomiłem traceroute na stronie www.btfl.com i, ku mojemu zaskoczeniu, niektóre przeskoki wróciły pod adresami RFC 1918.

Żeby było jasne, ten host nie znajduje się za moją zaporą ogniową i nie jest zaangażowany w VPN. Aby się tam dostać, muszę się połączyć przez otwarty internet.

Jak / dlaczego to jest możliwe?

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

i robi to samo z moim połączeniem FiOS w domu:

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.

Dozwolone jest łączenie się routerów za pomocą RFC1918 lub innych adresów prywatnych, a tak naprawdę jest to bardzo częste w przypadku połączeń typu punkt-punkt i każdego routingu, który odbywa się wewnątrz AS.

Tylko bramy graniczne w sieci rzeczywiście potrzebują publicznie trasowalnych adresów IP, aby routing działał. Jeśli interfejs routera nie łączy się z żadnym innym AS-em (lub innymi usługodawcami, prościej), nie ma potrzeby reklamowania trasy w Internecie, a tylko sprzęt należący do tego samego podmiotu będzie musiał bezpośrednio połączyć się z berło.

To, że pakiety zwracają się w ten sposób w traceroute, stanowi niewielkie naruszenie RFC1918, ale tak naprawdę nie jest konieczne używanie NAT dla tych urządzeń, ponieważ same nie łączą się z dowolnymi rzeczami w Internecie; po prostu przechodzą przez ruch uliczny.

To, że ruch odbywa się (prawdopodobnie okrężną) drogą przez kilka organizacji, co robi, jest jedynie konsekwencją działania zewnętrznych protokołów routingu bramy. Wydaje się całkowicie uzasadnione, że Microsoft ma jakiś kręgosłup i niektórzy ludzie się nim przyglądali; nie musisz być hurtowym dostawcą usług internetowych, aby kierować ruchem.

To, że ruch przechodzi przez wiele serii routerów z prywatnymi adresami IP, przesyłając je przez te z publicznymi adresami IP, nie jest szczególnie dziwny - po prostu wskazuje (w tym przypadku), że dwie różne sieci na trasie kierowały ruchem przez własne routery które wybrali w ten sposób.

Nie tylko RFC 1918 ... ale także RFC 6598 , czyli 100.64.0.0/10przestrzeń CGN. Obie są sieciami prywatnymi, ale ta ostatnia jest ostatnio znormalizowana i mniej znana.

Z punktu widzenia traceroute nie jest to niczym niezwykłym. W rzeczywistości nie rozmawiasz bezpośrednio z tymi hostami 10space i 100space, wysyłasz pakiety z przyrostowo większymi TTL do routera następnego skoku. Aby uniknąć zbyt długiej odpowiedzi, ten link do Wikipedii podsumowuje ten proces.

Co jest niezwykłe jest to, że ten pakiet przemierza przestrzeń publiczną IP, a następnie poprzez tunelowanie IP do przestrzeni prywatnej raz jeszcze osiągnąć „publiczne” siatkę. 157.56.176.94jest własnością Microsoftu, a pakiet przechodzi przez sieci należące do MS, zanim trafi do prywatnej sieci ... więc to właśnie Microsoft wybiera z przestrzenią sieciową na obu końcach przestrzeni prywatnej. Reklamują trasy; inne routery robią to, co im kazano.

Zasadniczo nie, operatorzy sieci na ogół nie narażają swoich prywatnych sieci na drodze do publicznej przestrzeni IP spoza ich sieci. Właśnie dlatego jest to tak niezwykłe.

(może to być brakująca trasa gdzieś na ich granicy, powodująca, że ​​pakiety przechodzą nieoptymalną ścieżkę, która ostatecznie dociera do miejsca docelowego, ale nie jestem facetem sieciowym i ktoś może prawdopodobnie lepiej go dźgnąć)