Две јавни 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 клиент излегува низ документираниот интернет излез. Трето, несаканите патеки на слушачот и на препраќањето остануваат одбиени. Запишете ги преписите од јавна во приватна адреса и сопствениците на секоја одлука од страна на гостинот и облакот на исто место.

Успешен тунел докажува само првиот дел. Тестирајте го излезот со нов тек, бидејќи кеширана врска може да го користи стариот извор долго по промената на рутата.