Два публични IP адреса на един Azure VPN VM: кой какво прави

Два публични IP адреса на един Azure VPN VM създават очакване, което рядко се сбъдва: адресът, към който се свързват клиентите, ще бъде и адресът, който виждат сайтовете. Три независими решения дават този резултат и само първото от тях е за слушателя на тунела. Второто е източникът в госта, използван за препратения клиентски трафик, а третото е методът за изходящ трафик в Azure, който се прилага към този източник. Променете едно и другите две остават там, където са, затова решавайте всяко изрично.

Решение 1: къде завършва тунелът

Публичен IP адрес в Azure се свързва с конфигурация за частен IP на NIC; това не е адрес, който добавяте вътре в гостевата операционна система. Прочетете връзката, вместо да я предполагате: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Какъвто и частен адрес да върне тази заявка, той е адресът, който гостът всъщност трябва да държи.

Една NIC може да носи няколко IP конфигурации, така че два публични адреса не изискват две NIC. Ако дизайнът наистина използва две NIC, всяка носи свои собствени маршрути в госта и следващи хопове и вие сте добавили решение за маршрутизация, вместо да го опростите.

За услуга с изрично локално обвързване се обвържете с реалния частен адрес на госта, никога с публичния заместител. Слушател, който приема всички адреси, получава трафик през всяка IP конфигурация, която го достига, затова ограничете входа с мрежовата група за сигурност и хостовата защитна стена, вместо да се надявате редът на обвързване да реши.

Решение 2: какъв източник използва препратеният клиент

След като шлюзът дешифрира клиентска заявка, пакетът, който препраща, е различен от пакета, пристигнал на VPN слушателя. Гостът се нуждае от включено препращане, политика на защитната стена, която разрешава потока, и адрес на източника, който дизайнът на облака позволява. Ако транслирате вътрешния адрес на клиента, именно транслираният източник ще оценява Azure, а не вътрешният адрес на клиента.

Тясно правило за SNAT може да избере частен източник в госта, но не може да надделее над последваща транслация в Azure. Изберете SNAT, когато ви трябва отчетност за всеки клиент вътре във VM; пропуснете го, когато изходящият дизайн на подмрежата вече дава стабилен публичен източник и втора транслация само би добавила състояние.

Решение 3: кой метод за изходящ трафик в Azure печели

Microsoft документираред на приоритет за изходящия трафик: приложим маршрут към устройство или шлюз има приоритет, а свързаността през NAT Gateway на подмрежата има приоритет пред публичен IP на ниво инстанция по съответния път. Този ред е причината транслация към 10.20.0.5 да не доказва, че сайтът ще види 198.51.100.20. Прочетете ефективната таблица на маршрутите, свързването с NAT Gateway и публичния IP на NIC заедно, преди да приемете дизайна на изхода.

Дръжтенастройката за препращане на Azure NICотделно от препращането в Linux. Флагът в облака разрешава пакети, чийто източник или дестинация не е назначен на NIC; той не включва net.ipv4.ip_forward и настройката в госта не дава разрешение от облака.

Тунелният сокет има свое решение за източника

Address в WireGuard под wg-quick задава адрес на интерфейса WireGuard; това не е инструкция за външно UDP обвързване. Източникът на криптирания сокет следва таблицата на маршрутите, затова политически маршрут или втори маршрут по подразбиране може да го премести, без да пипа адреса на интерфейса.OpenVPN: опцията local и UDP multihome се държат по същия начин: те се отнасят до слушателя и неговите отговори, а не до интернет източника на всеки препратен клиент.

Запазете маршрута на подлежащата мрежа, който носи тунела, и потвърдете, че клиентът все още получава удостоверени отговори от очакваната подредба на входа. Не разчитайте на реда в списъка с адреси като постоянна политика за избор на източник, защото следващият адрес, добавен към NIC, може да промени кой печели.

Какво да приемете и в какъв ред

Приемете три резултата поотделно. Първо, външен клиент достига предвидения VPN вход. Второ, нова разрешена заявка от този VPN клиент излиза през документирания интернет изход. Трето, нежеланите пътища на слушателя и на препращането остават отказани. Запишете съответствията публичен към частен адрес и собствениците на всяко решение от страна на госта и на облака на едно и също място.

Успешният тунел доказва само първата част. Тествайте изхода с нов поток, защото кеширана връзка може да продължи да използва стария източник дълго след промяната на маршрута.