Защо виртуална машина с VPN устройство в Azure губи обратния път
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 променя това, което натоварването вижда, затова правилата му за достъп трябва да описват модела, който наистина сте избрали, а не предполагаем адрес на шлюз.
Успешното ръкостискане доказва една връзка от тази верига. Пътят е пълен, когато отговорът се върне през същото устройство и собствената политика на натоварването го позволи.