Эмне үчүн Azure Point-to-Site VPN сиздин коомдук IP-ңызды өзгөртпөйт
Point-to-site туннели виртуалдык тармактын маршруттарын гана ташыйт, ошондуктан мажбурлап туннелдөө жана firewall SNAT чыгууну Azure-га жылдырмайынча коомдук IP-ңиз жергиликтүү бойдон калат.
Мен Windows ноутбугунда Azure VPN кардарын туташтырып, дарек-жаңыртуу барагын ачып, үй маршрутизаторум берген ошол эле коомдук даректи көрөм. Ошол эле учурда 10.20.0.4 дарегиндеги jump box жооп берет жана жеке endpoint аты чечилет, демек туннель бузулган эмес. Point-to-site шлюзу өзүнүн демейки конфигурациясы айтканды так аткарат: жеке префикстерди ташыйт, калганын жергиликтүү байланышта калтырат. Azure-га таандык чыгуу дарегин алуу — маршруттоо дизайнынын өзгөрүшү, оңдоо эмес.
Шлюз демейки боюнча эмнени жарыялайт
Шлюз виртуалдык тармактын дарек мейкиндиги үчүн маршруттарды, ошондой эле шлюз транзитине уруксат берилген тең тармактарды жана site-to-site туташуусу же BGP аркылуу үйрөнүлгөн жергиликтүү префикстерди жөнөтөт. Бул топтомдо 0.0.0.0/0 жок. Операциялык системаңыз демейки маршрутун Wi-Fi же Ethernet-де кармайт, ошондуктан коомдук API-ге бара жаткан пакет туннелге такыр кирбейт.
Кардар туннелдин ичинде алган дарек point-to-site пулунан алынган жеке ижара. Ал кардарды VNet ресурстарына таанытат; бул интернет көрө алган дарек эмес жана SaaS API-ге багытталган чыгуучу сурамдын булагы катары эч качан көрүнбөйт. Ошол ижаранын тегерегинде курулган allowlist жазуусу иштей албайт, анын сатуучу журналдарында пайда болушун канча күтсөңүз да.
Бөлүнгөн туннель жана мажбурлап туннелдөө катар
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Алыскы кызмат көргөн даректи экинчи сап гана өзгөртөт. Таблицадагы калган нерсенин баары — чыгууну Azure ичинде текшерүү же которуу керек болгондо кабыл алган чыгым жана операциялык бет. Эгер бирөө сизден коомдук IP-ни өзгөртүүнү сураса, ал бүт оң баганды сурап жатат, кардардагы кичине түзөтүүнү эмес.
Бир нерсени кайра куруудан мурун атап өтүүгө татыктуу орто вариант бар. VNet ичиндеги proxy же шлюз VM сизге ошол жакка багыттоого боло турган колдонмолор үчүн контролдолуучу булак дарегин берет, кардардын демейки маршрутун жылдырбастан. Бул кадимки серептөөнү жергиликтүү калтырат жана Azure-дан бир гана API чакыруу келишин талап кылган өнөктөштү канааттандырат. Талап чын эле бүт трафикке тиешелүү болсо, ал ийгиликсиз болот, анткени proxy жөндөөсүн этибарга албаган нерсенин баары баары бир жергиликтүү чыгат.
Туннелди демейки маршрутту ташууга мажбурлаңыз
Виртуалдык тармак шлюзунда кардардын бүт интернет трафигин туннелге багыттоонун колдоого алынган жолу — point-to-site конфигурациясына ыңгайлаштырылган маршруттарды кошуу. Эки жарым бүт IPv4 мейкиндигин камтыйт жана ар бири жергиликтүү демейки маршруттан такыраак, ошондуктан кардар эч нерсени өчүрбөстөн аларды артык көрөт:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Бул сап көчүрүүгө даяр эмес, мисал катары берилген: адегенде Get-AzVirtualNetworkGateway аркылуу шлюз объектин алып, аны GWOBJ ордуна коюңуз, жана иштетүүдөн мурун SKU менен жайгаштыруу модели ыңгайлаштырылган маршруттарды кабыл аларын ырастаңыз. Ошол эле префикстер порталда point-to-site конфигурация бетинде көрүнөт, ал эми шлюзду али скрипттебей турган болсоңуз, аларды ошол жерде коюу коопсузураак.
Бул префикстерди өзгөртүү кардар пакетин жараксыз кылат. VPN кардар пакетин кайра жүктөп, кайра орнотуңуз, анткени маршруттар профилдин ичинде жүрөт. Эски профили менен кайра туташкан кардар эски маршрут топтомун сактайт, жана ага эч качан жетпеген өзгөртүүнү оңдоого бир саат жоготушуңуз мүмкүн.
Корголгон виртуалдык WAN хабында эквивалент — point-to-site шлюзу менен байланышкан хаб маршруттар таблицасындагы демейки маршрут, ал эми трафикти хабдагы Azure Firewall алат. Firewall интернетке багытталган туташууларды өзүнүн коомдук IP даректерине которот, жаңы чыгуу дареги ушул которуудан келип чыгат. Firewall-дын бир нече коомдук IP-си болсо, алардын кайсынысы болбосун булак катары көрүнүшү мүмкүн, ошондуктан allowlist алардын баарын камтышы керек.
Жогорудагы эки дизайн тең IPv4. Эки /1 префикси IPv6 үчүн эч нерсе кылбайт, ал эми point-to-site-тин IPv6 колдоосу теңдикке убада берүүдөн мурун айкалышты текшерүүгө туура келгидей тар.
Маршрутту текшериңиз, анан чыгууну
Пакетти кайра орнотуп, кайра туташкандан кийин кардар эки жарымды чындап орнотконун ырастаңыз. Windows-то Get-NetRoute -DestinationPrefix 0.0.0.0/1 жана 128.0.0.0/1 үчүн ушундай суроо туннель интерфейсин аташы керек, ал эми route print экөөнү тең баштапкы демейки маршрутуңуздун жанында көрсөтөт. Linux-то ip route show эки префиксти тизмеши керек; тизмебесе, профиль аларды эч качан ташыган эмес.
Андан кийин кардардан коомдук даректи кайра текшерип, ошол эле туташуу үчүн firewall журналын окуңуз. Булак которулган порт менен firewall-дын коомдук IP-си болушу керек. Эки маршрут тең бар болгондо дагы эле жергиликтүү чыгып жаткан кардар пакеттер Azure-га жетип, башка жол менен чыкканын билдирет: шлюз ички тармагындагы колдонуучу аныктаган маршрут, өзү жергиликтүү тармакка мажбурлап туннелденген firewall, же агымды которуудан мурун таштаган саясат.
Ошол сессияда бир жеке максатты кайра сынап көрүңүз. Өзгөртүүдөн кийин жооп берүүнү токтоткон jump host — жаңы префикстер бир нерсени кысып чыгарганынын кадимки белгиси: же мурун жарыяланган тар жергиликтүү маршрут, же эми жеке аймактарыңыз үчүн форвардери жок resolver-ге бара жаткан ат чечүү.
Бөлүнгөн туннелди качан тынч калтыруу керек
Максат жеке API-ге, жеке endpoint-ке же ички администратор бетине жетүү гана болсо, демейки жүрүм-турум арзаныраак жана тынчыраак. Мажбурлап туннелдөө firewall сааттарын жана маалыматты иштетүү төлөмдөрүн, узунураак жолду жана ар бир кардар агымы ийгиликсиз болушу мүмкүн болгон дагы бир жерди кошот. Ал сизди тынчсыздандырган жалгыз максаттан кыйла көп трафикти да кармайт.
Ага талап чыгуу жагынан айтылганда кайрылыңыз: өнөктөш туруктуу Azure дарегин көрүшү керек, коопсуздук туташуулардын журналга жазылып, текшерилишин каалайт, же маалымат бир контролдолуучу чекиттен чыгышы керек. Ошондо да дизайн ар бир колдонуучуга жалпы чыгуу берет, ошондуктан колдонуучу боюнча жоопкерчилик булак дарегинен эмес, колдонмодогу инсандыктан келиши керек.
Өзгөртүүнү жаппас мурун төрт нерсени ырастаңыз: орнотулган кардар пакети жаңы, эки /1 маршруту туннель интерфейсинде, жеке максат дагы эле жооп берет, жана алыскы кызматтын журналы firewall дарегин көрсөтөт.