Две јавне 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 конфигурацију која до њега дође, зато ограничите улаз мрежном безбедносном групом и host firewall-ом, уместо да се надате да ће редослед везивања одлучити.

Одлука 2: који извор користи прослеђени клијент

Након што gateway дешифрује клијентски захтев, пакет који прослеђује разликује се од пакета који је стигао на VPN слушалац. Госту треба омогућено прослеђивање, firewall правило које допушта ток и изворна адреса коју дизајн облака допушта. Ако преведете унутрашњу клијентску адресу, Azure ће вредновати управо тај преведени извор, а не унутрашњу адресу клијента.

Уско SNAT правило може одабрати приватни извор у госту, али не може надјачати низводно Azure превођење. Одаберите SNAT када вам треба одговорност по клијенту унутар VM-а; прескочите га када излазни дизајн подмреже већ даје стабилан јавни извор и друго превођење би само додало стање.

Одлука 3: која Azure метода излазног саобраћаја побеђује

Microsoft документујередослед приоритета излазног саобраћаја: применљива рута према уређају или gateway-у има приоритет, а повезаност подмреже преко NAT Gateway-а има приоритет над јавном IP адресом на нивоу инстанце на релевантној путањи. Због тог редоследа превођење на 10.20.0.5 не доказује да ће веб страница видети 198.51.100.20. Прочитајте ефективну табелу рута, повезаност са NAT Gateway-ом и јавну IP адресу NIC-а заједно пре него што прихватите дизајн излаза.

Држитепоставку прослеђивања Azure NIC-аодвојено од Linux прослеђивања. Заставица у облаку допушта пакете чији извор или одредиште није додељен NIC-у; она не омогућује net.ipv4.ip_forward, а поставка у госту не даје дозволу облака.

Тунелски socket има сопствену одлуку о извору

Address у WireGuard-у под wg-quick додељује адресу WireGuard интерфејсу; то није упутство за спољно UDP везивање. Извор шифрованог socket-а следи табелу рута, па га политичка рута или друга подразумевана рута може померити без дирања адресе интерфејса.OpenVPN: опција local и UDP multihome понашају се исто: тичу се слушаоца и његових одговора, а не интернет извора сваког прослеђеног клијента.

Сачувајте руту доњег слоја која носи тунел и потврдите да клијент и даље прима аутентификоване одговоре из очекиваног распореда улаза. Не ослањајте се на редослед листе адреса као трајну политику избора извора, јер следећа адреса додата NIC-у може променити која побеђује.

Шта прихватити и којим редом

Прихватите три резултата одвојено. Прво, спољни клијент достигне предвиђени VPN улаз. Друго, нови дозвољени захтев тог VPN клијента изађе кроз документовани интернет излаз. Треће, нежељени путеви слушаоца и прослеђивања остају одбијени. Забележите мапирања јавне у приватну адресу и власнике сваке одлуке на страни госта и облака на истом месту.

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