Два публічныя 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 разам, перш чым прыняць дызайн зыходу.

Трымайценаладу перасылкі NIC у Azureасобна ад перасылкі ў Linux. Сцяг воблака дазваляе пакеты, крыніца або прызначэнне якіх не прывязаныя да NIC; ён не ўключае net.ipv4.ip_forward, і гасцявая налада не дае дазволу воблака.

У тунельнага сокета сваё рашэнне аб крыніцы

Address у WireGuard пад wg-quick прызначае адрас інтэрфейсу WireGuard; гэта не інструкцыя знешняй прывязкі UDP. Крыніца шыфраванага сокета ідзе за табліцай маршрутаў, таму палітычны маршрут або другі маршрут па змаўчанні можа перамясціць яе, не кранаючы адрас інтэрфейсу.OpenVPN: опцыя local і UDP multihome паводзяць сябе гэтак жа: яны датычаць слухача і яго адказаў, а не інтэрнэт-крыніцы кожнага перанакіраванага кліента.

Захоўвайце маршрут базавага ўзроўню, які нясе тунель, і пацвердзіце, што кліент па-ранейшаму атрымлівае аўтэнтыфікаваныя адказы з чаканага ўваходу. Не разлічвайце на парадак спісу адрасоў як пастаянную палітыку выбару крыніцы, бо наступны адрас, дададзены да NIC, можа змяніць, які з іх пераможа.

Што прымаць і ў якім парадку

Прымайце тры вынікі асобна. Першы: знешні кліент дасягае патрэбнага ўваходу VPN. Другі: новы дазволены запыт ад гэтага кліента VPN выходзіць праз дакументаваны інтэрнэт-выхад. Трэці: непатрэбныя шляхі слухача і перасылкі застаюцца забароненымі. Запішыце сувязі публічнага і прыватнага адрасоў і ўладальнікаў кожнага рашэння з боку гасцявога асяроддзя і воблака ў адным месцы.

Паспяховы тунель даказвае толькі першую частку. Правярайце зыход новым патокам, бо кэшаванае злучэнне можа выкарыстоўваць старую крыніцу яшчэ доўга пасля змены маршруту.