Чому віртуальна машина Azure з VPN-пристроєм втрачає зворотний шлях
VPN-пристрою у віртуальній машині Azure потрібні узгоджені UDR, прапорець пересилання мережевої карти та політика гостьової системи. Простежте один запит філії через усі три.
Віртуальна машина Azure, на якій працює VPN-пристрій, перебуває всередині двох незалежних систем ухвалення рішень. Azure вирішує, звідки пакет залишає підмережу, використовуючи таблиці маршрутів і налаштування пересилання мережевої карти. Власна операційна система пристрою вирішує, чи пересилати розшифрований пакет далі. Тунель, який піднімається бездоганно, все одно може зазнати невдачі в другій системі, і саме там зупиняється більшість таких розгортань.
Три власники одного шляху
Візьміть мережу філії 192.168.50.0/24 і підмережу робочого навантаження 10.0.10.0/24, а пристрій розташований за адресою 10.0.0.4 у власній підмережі. Один запит торкається трьох окремих конфігурацій.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Кожним рядком у більшості організацій володіє окрема команда, тому ця несправність зазвичай надходить як три заявки замість однієї.
Маршрут, який вказує на пристрій
Пов'яжіть таблицю маршрутів із підмережею робочого навантаження і задайте префіксу філії наступний стрибок типу Virtual appliance з 10.0.0.4 як адресою. Використовуйте доступну приватну адресу пристрою, ніколи його публічну точку входу VPN. Наступний стрибок має бути адресою, до якої підмережа робочого навантаження вже може дістатися. Залиште решту маршрутизації робочого навантаження як є, якщо ви свідомо не вирішили замінити маршрут за замовчуванням.
Тримайте пристрій у його власній підмережі й переконайтеся, що маршрут, який надсилає трафік філії на пристрій, не перехоплює також власний вихідний шлях пристрою. Така петля виглядає як здоровий тунель без відповідей, і це вкрай неприємно налагоджувати о 2 годині ночі.
Прапорець мережевої карти, який усі забувають
В Azure є налаштування пересилання IP для кожної мережевої карти, і воно вимкнене за замовчуванням. Воно існує тому, що карта, яка пересилає, отримує пакети, адресовані чомусь іншому, а тихе відкидання їх — безпечне значення за замовчуванням для всіх інших.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true вмикає його для одного інтерфейсу. Настанови Microsoft щодо пересилання на мережевій карті вимагають цього налаштування на кожній підключеній карті, яка пересилає трафік, тому пристрою з однією картою воно все одно потрібне на цій карті.
Прапорець не є маршрутом і не є правилом брандмауера. Його ввімкнення дає дозвіл і більше нічого.
Що гостьова система робить із розшифрованим пакетом
Коли тунель завершується, власний стек пристрою ухвалює наступне рішення. У гостьовій системі Linux пересилання IPv4 — це налаштування часу виконання, і sysctl -w net.ipv4.ip_forward=1 воно діє до наступного завантаження. Збережіть його у файлі в /etc/sysctl.d/ замість цього. Пристрій виробника має свій еквівалент, а інструкції для Linux, вставлені в платформу виробника, зазвичай не роблять нічого.
Політика брандмауера гостьової системи знову окрема, як і група мережевої безпеки робочого навантаження. Дозвіл UDP 500 і 4500 до публічної адреси віртуальної машини захищає тунель; він нічого не каже про те, чи може розшифрований запит філії дістатися до порту робочого навантаження.
Простежте один запит і його відповідь
Виберіть один дозволений потік і простежте його від початку до кінця. Філії потрібен маршрут для 10.0.10.0/24 через з'єднання з майданчиком, пристрою потрібен шлях доставки до підмережі робочого навантаження, а підмережі робочого навантаження потрібен зворотний маршрут до філії.
Вирішіть заздалегідь, чи проєкт зберігає вихідну адресу філії, чи транслює її. NAT змінює те, що бачить робоче навантаження, тому його правила доступу мають описувати модель, яку ви справді обрали, а не передбачувану адресу шлюзу.
Успішне рукостискання доводить одну ланку цього ланцюга. Шлях завершений, коли відповідь повертається через той самий пристрій і власна політика робочого навантаження це дозволяє.