Бір Azure VPN VM-де екі жалпыға ашық IP: қайсысы не істейді
VPN пакеттерін қабылдайтын мекенжай клиенттің веб сұранысының жалпыға ашық көзін таңдамайды. Кіруді, шығуды және туннель байланысын бөлек шешіңіз.
Бір Azure VPN VM-де екі жалпыға ашық IP сирек орындалатын күту туғызады: клиенттер қосылатын мекенжай веб-сайттар көретін мекенжай да болады. Бұл нәтижені үш тәуелсіз шешім береді және тек біріншісі туннель тыңдаушысына қатысты. Екіншісі қайта бағытталған клиент трафигі үшін пайдаланылатын қонақ көзі, үшіншісі сол көзге қолданылатын Azure-дың шығыс әдісі. Біреуін өзгертсеңіз, қалған екеуі орнында қалады, сондықтан әрқайсысын анық шешіңіз.
1-шешім: туннель қайда аяқталады
Azure-дың жалпыға ашық IP-і NIC-тегі жеке IP конфигурациясымен байланысады; бұл қонақ операциялық жүйесінің ішінде қосатын мекенжай емес. Болжаудың орнына сәйкестікті оқыңыз: 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-дың кейінгі аудармасынан асып түсе алмайды. VM ішінде әр клиент бойынша жауапкершілік қажет болса, SNAT таңдаңыз; қосалқы желінің шығыс жобасы қазірдің өзінде тұрақты жалпыға ашық көз берсе және екінші аударма тек күйді қосатын болса, оны өткізіп жіберіңіз.
3-шешім: қай Azure шығыс әдісі жеңеді
Microsoftшығыс басымдылық тәртібінқұжаттайды: құрылғыға немесе шлюзге қолданылатын маршрут басымдылық алады, ал қосалқы желінің NAT Gateway қосылымы тиісті жолдағы инстанция деңгейіндегі жалпыға ашық IP-ден басым. Осы тәртіп себебінен 10.20.0.5-ке аудару веб-сайт 198.51.100.20-ні көретінін дәлелдемейді. Шығыс жобасын қабылдамас бұрын тиімді маршрут кестесін, NAT Gateway байланысын және NIC-тің жалпыға ашық IP-ін бірге оқыңыз.
КелесініAzure NIC қайта бағыттау параметрінLinux қайта бағыттауынан бөлек ұстаңыз. Бұлт жалаушасы көзі немесе межелісі NIC-ке тағайындалмаған пакеттерге рұқсат береді; ол net.ipv4.ip_forward параметрін қоспайды және қонақ параметрі бұлт рұқсатын бермейді.
Туннель сокетінің өз көз шешімі бар
wg-quick астындағы WireGuard-тың Address параметрі WireGuard интерфейсіне мекенжай тағайындайды; бұл сыртқы UDP байланысының нұсқауы емес. Шифрланған сокеттің көзі маршрут кестесіне сүйенеді, сондықтан саясат маршруты немесе екінші әдепкі маршрут оны интерфейс мекенжайына тиіспей жылжыта алады.OpenVPN-ның local опциясы және UDP multihome дәл осылай әрекет етеді: олар тыңдаушыға және оның жауаптарына қатысты, әр қайта бағытталған клиенттің интернет көзіне емес.
Туннельді таситын төменгі қабат маршрутын сақтаңыз және клиенттің күтілетін кіру құрылымынан әлі де аутентификацияланған жауаптар алатынын растаңыз. Мекенжайлар тізімінің ретіне тұрақты көз таңдау саясаты ретінде сүйенбеңіз, өйткені NIC-ке қосылатын келесі мекенжай қайсысы жеңетінін өзгертуі мүмкін.
Нені және қандай ретпен қабылдау керек
Үш нәтижені бөлек қабылдаңыз. Біріншіден, сыртқы клиент көзделген VPN кіруіне жетеді. Екіншіден, сол VPN клиентінің жаңа рұқсат етілген сұранысы құжатталған интернет шығысы арқылы шығады. Үшіншіден, көзделмеген тыңдаушы және қайта бағыттау жолдары қабылданбаған күйде қалады. Жалпыға ашықтан жекеге сәйкестіктерді және әр шешімнің қонақ пен бұлт иелерін бір жерде жазып қойыңыз.
Сәтті туннель тек бірінші бөлікті дәлелдейді. Шығысты жаңа ағынмен тексеріңіз, өйткені кэштелген қосылым маршрут өзгергеннен кейін де ұзақ уақыт ескі көзді пайдалана алады.