Что происходит при соединениях внутри и вне VPN-туннеля

  • Tutorial
Из писем в службу техподдержки Tucha рождаются настоящие статьи. Так, недавно к нам обратился клиент с запросом разъяснить, что происходит при соединениях внутри VPN-туннеля между офисом пользователя и средой в облаке, а также при соединениях вне VPN-туннеля. Поэтому весь текст, приведенный ниже, — это реальное письмо, которое мы отправили одному из клиентов в ответ на его вопрос. Конечно, изменили IP-адреса, чтобы не деанонимизировать клиента. Но, да, служба технической поддержки Tucha действительно славится своими развёрнутыми ответами и содержательными письмами. :-)

Конечно, мы понимаем, что для многих эта статья не станет открытием. Но, поскольку на Habr время от времени появляются статьи для начинающих администраторов, а также ввиду того, что эта статья появилась из реального письма реальному клиенту, мы всё же поделимся этой информацией и здесь. Есть большая вероятность, что кому-то она будет полезна.
Поэтому подробно объясняем, что происходит между сервером в облаке и офисом, если они объединены site-to-site сетью. Отметим, что при этом часть сервисов доступна только из офиса, а часть — откуда угодно из сети Интернет.

Сразу объясним, что наш клиент пожелал, чтобы на сервер 192.168.A.1 можно было откуда угодно приходить по RDP, подключаясь к A.A.A.2:13389, а к остальным службам — только из офиса (192.168.B.0/24), подключённого через VPN. Также у клиента было настроено изначально, что к машине 192.168.B.2 в офисе тоже можно было ходить по RDP откуда угодно, подключаясь к B.B.B.1:11111. Мы помогли организовать IPSec-соединения между облаком и офисом, и ИТ-специалист заказчика начал задавать вопросы о том, что будет в том или ином случае. Чтобы ответить на все эти вопросы, мы, собственно, и написали ему всё то, что вы можете прочесть ниже.


А теперь рассмотрим эти процессы более подробно.


Позиция первая


Когда что-то отправляется из 192.168.B.0/24 в 192.168.A.0/24 или из 192.168.A.0/24 в 192.168.B.0/24, оно попадает в VPN. То есть этот пакет дополнительно зашифровывается и передаётся между B.B.B.1 и A.A.A.1, но 192.168.A.1 видит пакет именно от 192.168.B.1. Они могут общаться между собой по любым протоколам. Обратные ответы точно так же передаются через VPN, значит, пакет из 192.168.A.1 для 192.168.B.1 будет отправлен как ESP-датаграмма из A.A.A.1 на B.B.B.1, которую на той стороне маршрутизатор развернёт, достанет из неё тот пакет и отдаст на 192.168.B.1 как пакет от 192.168.A.1.

Конкретный пример:

1) 192.168.B.1 обращается к 192.168.A.1, хочет установить TCP-соединение с 192.168.A.1:3389;

2) 192.168.B.1 отправляет запрос на установление соединения от 192.168.B.1:55555 (номер порта для обратной связи выбирает он сам, здесь и далее будем использовать номер 55555 как пример такого номера порта, который система выбирает при формировании TCP-соединения) на 192.168.A.1:3389;

3) операционная система, которая работает на компьютере с адресом 192.168.B.1, решает передать этот пакет на шлюзовый адрес маршрутизатора (192.168.B.254 в нашем случае), потому что других, более специфических маршрутов для 192.168.A.1, у неё нет, следовательно, она передаёт пакет по маршруту по умолчанию (0.0.0.0/0);

4) для этого она пытается найти MAC-адрес для IP-адреса 192.168.B.254 в кэш-таблице протокола ARP. Если он не обнаружен, отправляет с адреса 192.168.B.1 широковещательный who-has запрос к сети 192.168.B.0/24. Когда 192.168.B.254 в ответ отправляет ей свой MAC-адрес, система передаёт Ethernet-пакет для неё и заносит эту информацию в свою кэш-таблицу;

5) маршрутизатор принимает этот пакет и решает, куда его передать: у него прописана политика, согласно которой он должен все пакеты между 192.168.B.0/24 и 192.168.A.0/24 передавать по VPN-соединению между B.B.B.1 и A.A.A.1;

6) маршрутизатор формирует ESP-датаграмму от B.B.B.1 на A.A.A.1;

7) маршрутизатор решает, кому передать этот пакет, он отправляет его на, скажем, B.B.B.254 (шлюз интернет-провайдера), потому что более специфических маршрутов к A.A.A.1, чем 0.0.0.0/0, у него нет;

8) точно так же, как уже было сказано, он находит MAC-адрес для B.B.B.254 и передаёт пакет на шлюз интернет-провайдера;

9) интернет-провайдеры передают по своим сетям ESP-датаграмму от B.B.B.1 на A.A.A.1;

10) виртуальный маршрутизатор на A.A.A.1 принимает эту датаграмму, расшифровывает её и получает пакет от 192.168.B.1:55555 для 192.168.A.1:3389;

11) виртуальный маршрутизатор проверяет, кому его передать, находит в таблице маршрутизации сеть 192.168.A.0/24 и отправляет его напрямую к 192.168.A.1, поскольку имеет интерфейс 192.168.A.254/24;

12) для этого виртуальный маршрутизатор находит MAC-адрес для 192.168.A.1 и передаёт ему этот пакет через виртуальную Ethernet-сеть;

13) 192.168.A.1 получает этот пакет на порт 3389, соглашается установить соединение и формирует пакет в ответ от 192.168.A.1:3389 на 192.168.B.1:55555;

14) его система передаёт этот пакет на шлюзовый адрес виртуального маршрутизатора (192.168.A.254 в нашем случае), потому что других, более специфических маршрутов для 192.168.B.1, у неё нет, следовательно, она должна передать пакет по маршруту по умолчанию (0.0.0.0/0);

15) так же, как и в предыдущих случаях, система, которая работает на сервере с адресом 192.168.A.1, находит MAC-адрес 192.168.A.254, поскольку тот находится в одной сети с её интерфейсом 192.168.A.1/24;

16) виртуальный маршрутизатор принимает этот пакет и решает, куда его передать: у него прописана политика, согласно которой он должен все пакеты между 192.168.A.0/24 и 192.168.B.0/24 передавать по VPN-соединению между A.A.A.1 и B.B.B.1;

17) виртуальный маршрутизатор формирует ESP-датаграмму от A.A.A.1 для B.B.B.1;

18) виртуальный маршрутизатор решает, кому передать этот пакет, отправляет его на A.A.A.254 (шлюз интернет-провайдера, в этом случае, это тоже мы), потому что более специфических маршрутов к B.B.B.1, чем 0.0.0.0/0, у него нет;

19) интернет-провайдеры передают по своим сетям ESP-датаграмму с A.A.A.1 на B.B.B.1;

20) маршрутизатор на B.B.B.1 принимает эту датаграмму, расшифровывает её и получает пакет от 192.168.A.1:3389 для 192.168.B.1:55555;

21) он понимает, что его следует передать именно на 192.168.B.1, поскольку тот находится с ним в одной сети, следовательно, у того есть в таблице маршрутизации соответствующая запись, которая вынуждает его отправлять пакеты для всей 192.168.B.0/24 напрямую;

22) маршрутизатор находит MAC-адрес для 192.168.B.1 и передаёт ему этот пакет;

23) операционная система на компьютере с адресом 192.168.B.1 принимает пакет от 192.168.A.1:3389 для 192.168.B.1:55555 и инициирует следующие шаги для установления TCP-соединения.

В этом примере достаточно сжато и упрощённо (а здесь можно вспомнить ещё кучу деталей) описано, что происходит на уровнях 2-4. Уровни 1, 5-7 не рассмотрены.

Позиция вторая


Если с 192.168.B.0/24 что-то отправляется именно на A.A.A.2, оно идёт не в VPN, а напрямую. То есть если пользователь с адреса 192.168.B.1 обращается к A.A.A.2:13389, этот пакет натится с адреса B.B.B.1, проходит на A.A.A.2, а там маршрутизатор его принимает и передаёт на 192.168.A.1. 192.168.A.1 не знает ничего о 192.168.B.1, он видит пакет от B.B.B.1, поскольку тот его понатил. Поэтому ответ на этот запрос идёт по общему маршруту, он точно так же натится с адреса A.A.A.2 и идёт на B.B.B.1, а тот маршрутизатор этот ответ отдаёт на 192.168.B.1, тот видит ответ от A.A.A.2, к которому он и обращался.

Конкретный пример:

1) 192.168.B.1 обращается к A.A.A.2, хочет установить TCP-соединение с A.A.A.2:13389;

2) 192.168.B.1 отправляет запрос на установление соединения от 192.168.B.1:55555 (этот номер, как и в предыдущем примере, может быть другим) на A.A.A.2:13389;

3) операционная система, которая работает на компьютере с адресом 192.168.B.1, решает передать этот пакет на шлюзовый адрес маршрутизатора (192.168.B.254 в нашем случае), потому что других, более специфических маршрутов для A.A.A.2, у неё нет, а значит, она передаёт пакет по маршруту по умолчанию (0.0.0.0/0);

4) для этого она, как мы и упоминали в предыдущем примере, пытается найти MAC-адрес для IP-адреса 192.168.B.254 в кэш-таблице протокола ARP. Если он не обнаружен, отправляет с адреса 192.168.B.1 широковещательный who-has запрос к сети 192.168.B.0/24. Когда 192.168.B.254 в ответ отправляет ей свой MAC-адрес, система передаёт Ethernet-пакет для неё и заносит эту информацию в свою кэш-таблицу;

5) маршрутизатор принимает этот пакет и решает, куда его передать: у него прописана политика, согласно которой он должен натить (подменяя обратный адрес) все пакеты от 192.168.B.0/24 к другим узлам сети Интернет;

6) поскольку эта политика подразумевает, что обратный адрес при этом должен совпадать с младшим адресом на интерфейсе, через который будет передан этот пакет, маршрутизатор сначала решает, кому именно передать этот пакет, а он, как и в предыдущем примере, должен отправить его на B.B.B.254 (шлюз интернет-провайдера), потому что более специфических маршрутов к A.A.A.2, чем 0.0.0.0/0, у него нет;

7) следовательно, маршрутизатор подменяет обратный адрес пакета, отныне пакет от B.B.B.1:44444 (номер порта, конечно, может быть другим) на A.A.A.2:13389;

8) маршрутизатор запоминает, что он сделал, значит, когда от A.A.A.2:13389 к B.B.B.1:44444 поступит ответ, он будет знать, что ему следует изменить адрес и порт получателя на 192.168.B.1:55555.

9) теперь маршрутизатор должен передать его к сети интернет-провайдера через B.B.B.254, следовательно, точно так же, как мы уже упоминали, он находит MAC-адрес для B.B.B.254 и передаёт пакет на шлюз интернет-провайдера;

10) интернет-провайдеры передают по своим сетям пакет от B.B.B.1 на A.A.A.2;

11) виртуальный маршрутизатор на A.A.A.2 принимает этот пакет на порт 13389;

12) на виртуальном маршрутизаторе есть правило, которое предусматривает, что пакеты, которые поступили от любого отправителя на этот порт, следует передавать на 192.168.A.1:3389;

13) виртуальный маршрутизатор находит в таблице маршрутизации сеть 192.168.A.0/24 и отправляет его напрямую 192.168.A.1, поскольку имеет интерфейс 192.168.A.254/24;

14) для этого виртуальный маршрутизатор находит MAC-адрес для 192.168.A.1 и передаёт ему этот пакет через виртуальную Ethernet-сеть;

15) 192.168.A.1 получает этот пакет на порт 3389, соглашается установить соединение и формирует пакет в ответ от 192.168.A.1:3389 на B.B.B.1:44444;

16) его система передаёт этот пакет на шлюзовый адрес виртуального маршрутизатора (192.168.A.254 в нашем случае), потому что других, более специфических маршрутов для B.B.B.1, у неё нет, следовательно, она должна передать пакет по маршруту по умолчанию (0.0.0.0/0);

17) точно так же, как и в предыдущих случаях, система, которая работает на сервере с адресом 192.168.A.1, находит MAC-адрес 192.168.A.254, поскольку тот находится в одной сети с её интерфейсом 192.168.A.1/24;

18) виртуальный маршрутизатор принимает этот пакет. Следует отметить, он помнит, что получал на A.A.A.2:13389 пакет от B.B.B.1:44444 и менял ему адрес и порт получателя на 192.168.A.1:3389, следовательно, пакету от 192.168.A.1:3389 для B.B.B.1:44444 он меняет адрес отправителя на A.A.A.2:13389;

19) виртуальный маршрутизатор решает, кому передать этот пакет, он отправляет его на A.A.A.254 (шлюз интернет-провайдера, в этом случае, это тоже мы), потому что более специфических маршрутов к B.B.B.1, чем 0.0.0.0/0, у него нет;

20) интернет-провайдеры передают по своим сетям пакет с A.A.A.2 на B.B.B.1;

21) маршрутизатор на B.B.B.1 принимает этот пакет и вспоминает, что, когда он передавал пакет от 192.168.B.1:55555 для A.A.A.2:13389, он менял его адрес и порт отправителя на B.B.B.1:44444, значит, это ответ, который нужно передать на 192.168.B.1:55555 (на самом деле, там существуют ещё несколько проверок, но мы в это не углубляемся);

22) он понимает, что его следут передать напрямую на 192.168.B.1, поскольку тот находится с ним в одной сети, следовательно, у того есть в таблице маршрутизации соответствующая запись, которая заставляет отправлять пакеты для всей 192.168.B.0/24 напрямую;

23) маршрутизатор находит MAC-адрес для 192.168.B.1 и передаёт ему этот пакет;

24) операционная система на компьютере с адресом 192.168.B.1 принимает пакет от A.A.A.2:13389 для 192.168.B.1:55555 и инициирует следующие шаги для установления TCP-соединения.

Следует отметить, что в этом случае компьютер с адресом 192.168.B.1 ничего не знает о сервере с адресом 192.168.A.1, он общается только с A.A.A.2. Точно так же и сервер с адресом 192.168.A.1 ничего не знает о компьютере с адресом 192.168.B.1. Он считает, что к нему подключились с адреса B.B.B.1, а больше он ничего, так сказать, не знает.

Ещё следует отметить, что в случае, если этот компьютер обращается к A.A.A.2:1540, соединение не будет установлено, потому что проброс соединений на порт 1540 не настроен на виртуальном маршрутизаторе, даже если на каких-либо серверах в виртуальной сети 192.168.A.0/24 (например, на сервере с адресом 192.168.A.1) и есть какие-нибудь сервисы, которые ждут соединения на этом порту. Если пользователю компьютера с адресом 192.168.B.1 крайне необходимо установить соединение с этой службой, он должен использовать VPN, т.е. обращаться напрямую на 192.168.A.1:1540.

Следует подчеркнуть, что любые попытки установить соединение с A.A.A.1 (кроме IPSec-соединения со стороны B.B.B.1 не будут удачными. Любые попытки установить соединения с A.A.A.2, кроме соединений с портом 13389, тоже не будут удачными.
Также отметим, что в случае, если к A.A.A.2 обратится кто-нибудь ещё (например, C.C.C.C), всё, что обозначено в пунктах 10-20, будет касаться и его тоже. Что происходит до этого и после этого зависит от того, что именно находится за этим C.C.C.C. Мы не владеем такой информацией, поэтому советуем обратиться за консультациями к администраторам узла с адресом C.C.C.C.

Позиция третья


И, наоборот, если с 192.168.A.1 что-либо отправляется на какой-нибудь порт, который сконфигурирован для проброса внутрь на B.B.B.1 (например, 11111), оно также не попадает в VPN, а просто натится от A.A.A.1 и попадает в B.B.B.1, а тот уже передаёт его куда-нибудь в, скажем, 192.168.B.2:3389. Тот видит этот пакет не от 192.168.A.1, а от A.A.A.1. И, когда 192.168.B.2 отвечает, пакет идёт от B.B.B.1 на A.A.A.1, а позже попадает к инициатору соединения — 192.168.A.1.

Конкретный пример:

1) 192.168.A.1 обращается к B.B.B.1, хочет установить TCP-соединение с B.B.B.1:11111;

2) 192.168.A.1 отправляет запрос на установление соединения от 192.168.A.1:55555 (этот номер, как и в предыдущем примере, может быть другим) на B.B.B.1:11111;

3) операционная система, которая работает на сервере с адресом 192.168.A.1, решает передать этот пакет на шлюзовый адрес маршрутизатора (192.168.A.254 в нашем случае), потому что других, более специфических маршрутов для B.B.B.1, у неё нет, следовательно, она передаёт пакет по маршруту по умолчанию (0.0.0.0/0);

4) для этого она, как мы и упоминали в предыдущих примерах, пытается найти MAC-адрес для IP-адреса 192.168.A.254 в кэш-таблице протокола ARP. Если он не обнаружен, отправляет с адреса 192.168.A.1 широковещательный who-has запрос к сети 192.168.A.0/24. Когда 192.168.A.254 в ответ отправляет ей свой MAC-адрес, система передаёт Ethernet-пакет для него и заносит эту информацию в свою кэш-таблицу;

5) виртуальный маршрутизатор принимает этот пакет и решает, куда его передать: у него прописана политика, согласно которой он должен натить (подменяя обратный адрес) все пакеты от 192.168.A.0/24 к другим узлам сети Интернет;

6) поскольку эта политика предполагает, что обратный адрес при этом должен совпадать с младшим адресом на интерфейсе, через который будет передан этот пакет, виртуальный маршрутизатор сначала решает, кому именно передать этот пакет, а он, как и в предыдущем примере, должен отправить его на A.A.A.254 (шлюз интернет-провайдера, в этом случае, это тоже мы), потому что более специфических маршрутов к B.B.B.1, чем 0.0.0.0/0, у него нет;

7) значит, виртуальный маршрутизатор подменяет обратный адрес пакета, отныне это пакет от A.A.A.1:44444 (номер порта, конечно, может быть другим) на B.B.B.1:11111;

8) виртуальный маршрутизатор запоминает, что он сделал, следовательно, когда от B.B.B.1:11111 для A.A.A.1:44444 поступит ответ, он будет знать, что ему следует изменить адрес и порт получателя на 192.168.A.1:55555.

9) теперь виртуальный маршрутизатор должен передать его в сеть интернет-провайдера через A.A.A.254, значит, точно так же, как мы уже упоминали, он находит MAC-адрес для A.A.A.254 и передаёт пакет на шлюз интернет-провайдера;

10) интернет-провайдеры передают по своим сетям пакет от A.A.A.1 на B.B.B.1;

11) маршрутизатор на B.B.B.1 принимает этот пакет на порт 11111;

12) на виртуальном маршрутизаторе существует правило, которое предусматривает, что пакеты, которые поступили от какого-либо отправителя на этот порт, следует передавать на 192.168.B.2:3389;

13) маршрутизатор находит в таблице маршрутизации сеть 192.168.B.0/24 и отправляет его напрямую к 192.168.B.2, поскольку имеет интерфейс 192.168.B.254/24;

14) для этого виртуальный маршрутизатор находит MAC-адрес для 192.168.B.2 и передаёт ему этот пакет через виртуальную Ethernet-сеть;

15) 192.168.B.2 получает этот пакет на порт 3389, соглашается установить соединение и формирует пакет в ответ от 192.168.B.2:3389 на A.A.A.1:44444;

16) его система передаёт этот пакет на шлюзовый адрес маршрутизатора (192.168.B.254 в нашем случае), потому что других, более специфических маршрутов для A.A.A.1, у неё нет, следовательно, она должна передать пакет по маршруту по умолчанию (0.0.0.0/0);

17) точно так же, как и в предыдущих случаях, система, которая работает на компьютере с адресом 192.168.B.2, находит MAC-адрес 192.168.B.254, поскольку тот находится в одной сети с её интерфейсом 192.168.B.2/24;

18) маршрутизатор принимат этот пакет. Следует отметить, он помнит, что получал на B.B.B.1:11111 пакет от A.A.A.1 и менял ему адрес и порт получателя на 192.168.B.2:3389, следовательно, пакету от 192.168.B.2:3389 для A.A.A.1:44444 он меняет адрес отправителя на B.B.B.1:11111;

19) маршрутизатор решает, кому передать этот пакет. Он отправляет его на, скажем, B.B.B.254 (шлюз интернет-провайдера, точный адрес которого мы не знаем), потому что более специфических маршрутов к A.A.A.1, чем 0.0.0.0/0, у него нет;

20) интернет-провайдеры передают по своим сетям пакет с B.B.B.1 на A.A.A.1;

21) виртуальный маршрутизатор на A.A.A.1 принимает этот пакет и вспоминает, что, когда он передавал пакет от 192.168.A.1:55555 для B.B.B.1:11111, он менял его адрес и порт отправителя на A.A.A.1:44444. Значит, это ответ, который необходимо передать на 192.168.A.1:55555 (на самом деле, как мы и упоминали в предыдущем примере, там тоже есть ещё несколько проверок, но и в этот раз мы в них не углубляемся);

22) он понимает, что его следует передать напрямую на 192.168.A.1, поскольку тот находится с ним в одной сети, значит, у того есть в таблице маршрутизации соответствующая запись, которая заставляет его отправлять пакеты для всей 192.168.A.0/24 напрямую;

23) маршрутизатор находит MAC-адрес для 192.168.A.1 и передаёт ему этот пакет;

24) операционная система на сервере с адресом 192.168.A.1 принимает пакет от B.B.B.1:11111 для 192.168.A.1:55555 и инициирует следующие шаги для установления TCP-соединения.

Точно так же, как и в предыдущем случае, в этом случае сервер с адресом 192.168.A.1 ничего не знает о компьютере с адресом 192.168.B.1, он общается только с B.B.B.1. Компьютер с адресом 192.168.B.1 тоже ничего не знает о сервере с адресом 192.168.A.1. Он считает, что к нему подключились с адреса A.A.A.1, а остальное от него спрятано.

Вывод


Вот так всё происходит при соединениях внутри VPN-туннеля между офисом клиента и средой в облаке, а также при соединениях вне VPN-туннеля. А если у вас остались вопросы или нужна наша помощь в решении облачных задач, обращайтесь 24х7.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 7

    +1
    Конечно, мы понимаем, что для многих эта статья не станет открытием. Но, поскольку на Habr время от времени появляются статьи для начинающих администраторов, а также ввиду того, что эта статья появилась из реального письма реальному клиенту, мы всё же поделимся этой информацией и здесь.

    О, да. Я помню те дни, когда впервые начал играться с маршрутами, таблицами и NATом. Примеры — это наглядно и хорошо, особенно, если тот кто читает, напечатает ту картинку из статьи и проходя по пунктам на ней будет делать пометки об мутации пакета и маршрутов, но пока сам не начнёшь руками строить сеть, пусть и виртуальную, пока не получишь первое своё кольцо или блэкхол — как говорится отличие теории и практики. Ну а после вдумчивого чтения мана на файерволл (для меня это был ipfw в FreeBSD) уже практически белых пятен не остаётся. Хорошая статья, особенно для тех, кто только встал на путь сетевого администрирования.

    PS Но начинать всё же лучше без привлечения облака, там такая магия иногда происходит — просто туши свет кидай гранату. У меня есть много личных примеров, что трассировка между 2мя хостами у разных провайдеров в одном городе. Если трассировать из пункта А в Б, то всего 6 хопов, все логичные. Если обратно, то почти 12, половина вообще не понятно чьи. Начинающим лучше построить цепочку из 3х — 4х сетей, где крайние сети не видят напрямую друг друга и маршрутизируются через другую сеть. Пусть статичными маршрутами, зато будет понятна сама логика как это работает. Ну а после поднятия определенного уровня можно уже подключать NAT и облако.
      0
      В наш век виртуализации можно вообще наплодить кучу виртуальных машин и соединять их в самые причудливые сети. 20 годков назад я о таком и не мечтал. Правда, самая первая vmware как раз где-то в это время и появилась, я даже смог найти ей некоторое применение, но на несколько виртуальных машин мне тогда точно не хватило бы ресурсов, работал я тогда в очень скромном в плане ресурсов месте. :-)
      — В.М.
      0
      О мой всевышний! Может можно было как-то проще, через Ethernet-over-IP поверх туннеля и в нем МАК-бриджинг?
        0
        Я, честно говоря, не вижу тут ничего сложного, хотя при необходимости в самом деле можно было объединить их в одну IP-сеть. Только тут именно должны быть разные IP-сети, поскольку, когда таких офисов будет подключаться несколько, объединять их всех в одну широковещательную сеть было бы, мягко говоря, не очень разумно. =)
        — В.М.
          +1
          Я помню реальную историю объединения двух корпусов одного учреждения через радиомост на основе Cisco BR350 лет 16 назад. Так вот, пока сети были разрознены и почта ходила через MDaemon путём прямого прозвона модемом обе сети предыдущий админ настроил в одной подсети. Когда встал вопрос объединения для повышения качества хождения почты и не только уже тогда я изменил подсеть одного корпуса специально, чтобы исключить ненужный флуд в радиосети, т.к. она же полудуплексная. Яркий пример, почему не следует объединять 2 сети через TAP. Однако, бывают исключения, ну или когда подключается только 1 клиент, тогда TAP самое подходящее, чтобы заработало сразу и из коробки, без вникания в тонкости всяких маршрутизаций и фильтраций.
            0
            Насколько я помню, в микротиках можно было как-то настраивать фильтрацию по мак-адресам? Т.е. всё что приходит с определенного порта (eoip1) маркировать определенным образом и не пропускать эти фрэймы на какие-то ресурсы внутри ether1?
              0
              Можно, но это уже как раз и усложнение на ровном месте, как по мне. :-)
              — В.М.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое