Великолепно! Но что происходит за кулисами?
А там, ребята, удивительные вещи:
Когда вы запускаете ping 10.1.1.0, что делает маршрутизатор?
1) Формирует IP-пакет::
2) Смотрит таблицу маршрутизации
R1#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «static», distance 1, metric 0
Routing Descriptor Blocks:
10.2.2.2
Route metric is 0, traffic share count is 1
Далее рекурсивно смотрит, где адрес 10.2.2.2:
R1#sh ip rou 10.2.2.2
Routing entry for 10.2.2.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
Такссс, Tunnel 0:
R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
3) Понимая, что это GRE-туннель, добавляет к пакету заголове GRE:
А сверху новый заголовок IР. В качестве отправителя будет значиться адрес tunnel source, а в качестве получателя – tunnel destination.
4) Новоиспечённый пакет отправляется в дивный мир по дефолтному маршруту:
R1#sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0
5) Не забываем про заголовок Ethernet, при отправке провайдеру он также должен быть сформирован.
Поскольку GRE-туннель – виртуальный интерфейс 3-го уровня, он не обладает собственным MAC-адресом (как и Loopback, например). В конечном итоге кадр уйдёт с физического интерфейса FastEthernet0/0:
R1#sh ip route 100.0.0.2
Routing entry for 100.0.0.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1
Соответственно его адрес он и укажет в качестве Source MAC
R1#sh int
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c000.25a0.0000 (bia c000.25a0.0000)
Internet address is 100.0.0.1/30
Destination по традиции берётся из ARP-кэша или получается с помощью ARP-запроса от адреса 100.0.0.2:
R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 100.0.0.1 – c000.25a0.0000 ARPA FastEthernet0/0
Internet 100.0.0.2 71 c001.25a0.0000 ARPA FastEthernet0/0
6) И в таком виде новый IP-пакет передаётся в интернет. А поскольку каждый маршрутизатор не раздербанивает пакет, а принимает решение на основе первого же заголовка IP, то никто в Интернете не будет знать о том, что где-то там внутри кроются ваши приватные адреса 10.1.1.0 и 10.0.0.0.
7) И наконец пребывает в точку назначения.
R3 обнаруживает, что адрес назначения принадлежит ему самому, снимает заголовок IP и что он под ним находит? GRE-заголовок.
Он проверяет, что у него действительно есть такой GRE-туннель, снимает заголовок GRE, и дальше это уже самый обычный IP-пакет, с которым нужно распорядиться согласно записям в таблице маршрутизации.
В данном случае передать на обработку интерфейсу Loopback 0
R3#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
directly connected, via Loopback0
Route metric is 0, traffic share count is 1
Вот такие нехитрые манипуляции.
Пока пакет в локальной сети он выглядит так:
и обрабатывается на основе приватных адресов.
Как только попадает в публичную сеть, GRE вешает на него дополнительный IP-заголовок:
и пакет обрабатывается на основе публичных адресов.
Вот как выглядит пакет в Интернете:
1 – изначальные данные
2 – первый IP-заголовок (внутренний)
3 – заголовок GRE (с указанием, что внутри лежат данные протокола IP)
4 – новый заголовок IP (внешний, с туннельными адресами)
Рядовой обмен ICMP-сообщениями может при детальном рассмотрении выглядеть и так.
