Як здійснюється маршрутизація мого пакету GRE-тунелів? [зачинено]


0

Я намагаюся з’ясувати, що саме відбувається, коли я створюю тунель GRE.

Моя мережа виглядає так (-> означає безпосередньо підключений):

  • Комп'ютер A (eth0: 10.0.1.1) ->
  • (eth0: 10.0.1.2) Маршрутизатор B (eth1: 10.0.2.1) ->
  • (eth0: 10.0.2.2) Маршрутизатор C (eth1: 10.0.3.1) ->
  • (eth0: 10.0.3.2) Маршрутизатор D (eth1: 10.0.4.1) ->
  • (ет.: 10.0.4.2) Комп'ютер E

Я виконав наступні команди на маршрутизаторі B:

ip tunnel add Tunnel5 mode gre local 10.0.2.1 remote 10.0.3.2
ifconfig Tunnel5 192.168.33.2 netmask 255.255.255.0 up
ip route add 10.0.4.2/32 via 192.168.33.3

із наступною інформацією про з'єднання:

conn routerD_eth0
    type=tunnel
    authby=secret
    left=10.0.2.1
    leftsubnet=10.0.2.1/32
    right=10.0.3.2
    rightsubnet=10.0.3.2/32
    auto=start

І еквівалент на маршрутизаторі D:

ip tunnel add Tunnel5 mode gre local 10.0.3.2 remote 10.0.2.1
ifconfig Tunnel5 192.168.33.3 netmask 255.255.255.0 up
ip route add 10.0.1.1/32 via 192.168.33.2

з

conn routerb_eth1
    type=tunnel
    authby=secret
    left=10.0.3.2
    leftsubnet=10.0.3.2/32
    right=10.0.2.1
    rightsubnet=10.0.2.1/32
    auto=start

Це те, що я можу спостерігати на маршрутизаторі A, якщо переходжу з комп'ютера A на комп'ютер B:

  1. Трафік надходить у eth0 із призначенням 10.0.4.2.

  2. Трафік спрямовується на новий інтерфейс Tunnel5: Викликаний правилом маршрутизації, який я додав (ip route add 10.0.4.2/32 через 192.168.33.3)

  3. ??? Магія ??? Якимось чином трафік інкапсулюється та направляється назад до маршрутизатора з новою адресою призначення 10.0.3.2

  4. Звичайні правила маршрутизації OSPF призводять до того, що трафік виходить з етикету1 і переходить до місця призначення.

Що відбувається на кроці 3?

Додаткова інформація

Деякі команди та їх вихідні дані виконуються на маршрутизаторі A:

$ ip tunnel show
Tunnel5: gre/ip remote 10.0.3.2 local 10.0.2.1

$ setkey -DP
10.0.3.2[any] 10.0.2.1[any] 255
    ...
    /esp/tunnel/10.0.3.2-10.0.2.1/unique:3
    ...

10.0.2.1[any] 10.0.3.2[any] 255
    ...
    /esp/tunnel/10.0.2.1-10.0.3.2/unique:3
    ...

Теорія

Маршрутизатор просто знає, виходячи з інформації в "ip tunnel show", що трафік, спрямований на Tunnel5, повинен бути інкапсульований новим джерелом та адресою призначення.

Інкапсульований пакет повинен бути просто спрямований як звичайний. У цьому випадку Політики IPSec узгоджують і шифрують пакет, зберігаючи вихідні та цільові адреси.

Потім пакет спрямовується на основі таблиці маршрутизації до маршрутизатора C.

Просто здогадка.


Можливо, ви хочете перенести це на networkengineering.stackexchange.com
ETL

Не знав, що існує! Я не знаю, як рухати чи закривати речі, не думаю, що можу. Я повторно подав його на іншому веб-сайті. Якщо хтось хоче закрити це, було б приголомшливо! -Спасибі
exxodus7

Відповіді:


1

Коли пакет потрапляє в маршрутизатор, він маршрутизується через тунельний інтерфейс через ваш статичний маршрут. маршрутизатор інкапсулює пакет у пакет GRE, з пунктом призначення 10.0.3.2. Потім маршрутизатор спрямовує цей пакет відповідно до таблиці маршрутизації (тобто, з eth 1). Коли він потрапляє на маршрутизатор D, пакет декапсулюється і потім нормально маршрутизується.


Отже (логічно кажучи) пакет йде від маршрутизатора -> інтерфейсу тунелю, де він інкапсульований у gre tunel -> назад до маршрутизатора -> інкапсульований в тунель ipsec (де інкапсуляція має те саме джерело, призначення, як gre tunel) і направлений eth1 на основі таблиці маршрутизації?
exxodus7

Ще один спосіб сказати, що ... чи є тут два тунелі? Тунель GRE та тунель IPSec, який потім інкапсулює тунель GRE?
exxodus7

Я не бачив частини IPSEC, але так, пакети GRE потім інкапсулюються в пакет IPSEC ESP. Отже, отримайте пакет, інкапсулюйте, інкапсулюйте знову і потім вперед.
Рон Трунк

Дивовижне, дякую! І після того, як я запускаю свій біт створення тунелів, я бачу нові політики IPSec (думаю, це з конфігурації "conn ...").
exxodus7
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.