Що відбувається при з’єднаннях всередині та поза VPN-тунелем

  1. Головна
  2. Блог
  3. Авторська колонка
  4. Що відбувається при з’єднаннях всередині та поза VPN-тунелем
Категорії

З листів до служби техпідтримки Tucha народжуються справжні статті. Так, нещодавно до нас звернувся клієнт із запитом роз’яснити, що відбувається при з'єднаннях всередині VPN-тунелю між офісом користувача та середовищем у хмарі, а також при з’єднаннях поза VPN-тунелем. Тож увесь текст, наведений нижче, — це реальний лист, який ми надіслали одному з клієнтів у відповідь на його запитання. Звісно, змінили IP-адреси, аби не деанонімізувати клієнта. Але, так, служба технічної підтримки Tucha справді славиться своїми розгорнутими відповідями та змістовними листами. :-)

Тож детально пояснюємо, що відбувається між сервером у хмарі та офісом, якщо вони об'єднані 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-з'єднання між хмарою та офісом, і ІТ-фахівець замовника почав ставити запитання про те, що буде в тому чи іншому випадку. Щоб відповісти на всі ці питання, ми, власне, і написали йому все те, що ви можете прочитати нижче.

0зощрш

А тепер розглянемо ці процеси більше детально. 

Позиція перша

Коли щось відправляється з 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.

Поділитися:
Статті по темі

Ділимося корисною інформацією для користувачів віртуальних машин. До служби техпідтримки Tucha досить часто звертаються клієнти з питанням, як налаштувати прокидання портів до сервера...

Сьогодні розповімо вам про те, як ефективно захистити свої дані на хмарному сервері, сховавши сервер в приватну мережу

При роботі користувачів на віртуальних серверах важливим аспектом є правильне завершення робочого сеансу. Від цього значно залежить безпека і цілісність даних, а також продуктивність роботи самого сервера. У статті розглянемо докладніше, що слід зробити перед виходом з сервера, як коректно завершити сеанс та яких ризиків це допоможе уникнути надалі. 

Виконати блокування або видалення можна всього за декілька простих кроків, і в цій інструкції покажемо, як це зробити.

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

В цій статті детально розповідаємо про особливості кожного з видів технічної підтримки Tucha та допомагаємо розібратися, який з них підійде для вирішення тих чи інших задач.

Закрити
Замовити зворотний дзвінок

Будь ласка, перевірте правильність заповнення поля з номером телефону

Поля обов'язкові для заповнення.
Цей сайт захищено reCAPTCHA та приймаються Політика конфеденційності й Умови користування від Google.

Ми використовуємо cookies.

Ми використовуємо файли cookies, щоб забезпечити основні функціональні можливості на нашому сайті і збирати дані про те, як відвідувачі взаємодіють з нашим сайтом, продуктами і послугами. Натискаючи Прийняти або продовжуючи використовувати цей сайт, ви погоджуєтеся з тим, що ми використовуємо ці інструменти для реклами і аналітики згідно з «Політикою про файли сookies»

ПрийнятиВідмовитись