Из писем в службу техподдержки 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 jew minn 192.168.A.0/24 в 192.168.B.0/24, оно попадает в VPN. То есть этот пакет дополнительно зашифровывается и передаётся между B.B.B.1 и A.A.A.1Imma 192.168.A.1 видит пакет именно от 192.168.B.1. Они могут общаться между собой по любым протоколам. Обратные ответы точно так же передаются через VPN, значит, пакет из 192.168.A.1 għall- 192.168.B.1 будет отправлен как ESP-датаграмма из A.A.A.1 fuq B.B.B.1, которую на той стороне маршрутизатор развернёт, достанет из неё тот пакет и отдаст на 192.168.B.1 как пакет от 192.168.A.1.
Конкретный пример:
1) 192.168.B.1 jirreferi għal 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. Meta 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 fuq 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 fuq A.A.A.1;
10) виртуальный маршрутизатор на A.A.A.1 принимает эту датаграмму, расшифровывает её и получает пакет от 192.168.B.1:55555 għall- 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 fuq 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 għall- B.B.B.1;
18) виртуальный маршрутизатор решает, кому передать этот пакет, отправляет его на A.A.A.254 (шлюз интернет-провайдера, в этом случае, это тоже мы), потому что более специфических маршрутов к B.B.B.1, чем 0.0.0.0/0, у него нет;
19) интернет-провайдеры передают по своим сетям ESP-датаграмму с A.A.A.1 fuq B.B.B.1;
20) маршрутизатор на B.B.B.1 принимает эту датаграмму, расшифровывает её и получает пакет от 192.168.A.1:3389 għall- 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 għall- 192.168.B.1:55555 и инициирует следующие шаги для установления TCP-соединения.
В этом примере достаточно сжато и упрощённо (а здесь можно вспомнить ещё кучу деталей) описано, что происходит на уровнях 2-4. Уровни 1, 5-7 не рассмотрены.
Позиция вторая
Jekk ma 192.168.B.0/24 что-то отправляется именно на A.A.A.2, оно идёт не в VPN, а напрямую. То есть если пользователь с адреса 192.168.B.1 jirreferi għal 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 jirreferi għal 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. Meta 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 fuq 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 fuq 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 għall- 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 fuq B.B.B.1;
21) маршрутизатор на B.B.B.1 принимает этот пакет и вспоминает, что, когда он передавал пакет от 192.168.B.1:55555 għall- 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 għall- 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 fuq A.A.A.1, а позже попадает к инициатору соединения — 192.168.A.1.
Конкретный пример:
1) 192.168.A.1 jirreferi għal 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. Meta 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 għall- 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 fuq 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 għall- 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 fuq A.A.A.1;
21) виртуальный маршрутизатор на A.A.A.1 принимает этот пакет и вспоминает, что, когда он передавал пакет от 192.168.A.1:55555 għall- 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 għal 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, а остальное от него спрятано.
Output
Вот так всё происходит при соединениях внутри VPN-туннеля между офисом клиента и средой в облаке, а также при соединениях вне VPN-туннеля. А если у вас остались вопросы или нужна наша помощь в решении облачных задач,
Sors: www.habr.com