Nega Azure Point-to-Site VPN sizning umumiy IP-manzilingizni o'zgartirmaydi
Point-to-site tunnel faqat virtual tarmoq yo'llarini olib o'tadi, shu sababli majburiy tunnel va firewall SNAT chiqishni Azure'ga ko'chirmaguncha umumiy IP-manzilingiz mahalliy bo'lib qoladi.
Windows noutbukida Azure VPN mijozi ulayman, manzil aks-sadosi sahifasini ochaman va uy routerim bergan o'sha umumiy manzilni ko'raman. Shu vaqtda 10.20.0.4 dagi sakrash qutisi javob beradi va xususiy endpoint nomi yechiladi, ya'ni tunnel buzilmagan. Point-to-site shlyuzi standart konfiguratsiyasi aytganini aniq bajaradi: xususiy prefikslarni olib o'tadi, qolgan hamma narsani mahalliy havolada qoldiradi. Azure'ga tegishli chiqish manzilini olish — marshrutlash dizaynining o'zgarishi, ta'mirlash emas.
Shlyuz sukut bo'yicha nima e'lon qiladi
Shlyuz virtual tarmoq manzil maydoni uchun yo'llarni, shuningdek shlyuz tranzitiga ruxsat berilgan teng tarmoqlarni va site-to-site ulanish yoki BGP orqali o'rganilgan mahalliy prefikslarni yuboradi. Bu to'plamda 0.0.0.0/0 yo'q. Operatsion tizimingiz standart yo'lni Wi-Fi yoki Ethernet'da ushlab turadi, shu sababli umumiy API'ga ketayotgan paket tunnelga umuman kirmaydi.
Mijoz tunnel ichida oladigan manzil point-to-site hovuzidan xususiy ijara. U mijozni VNet resurslariga tanitadi; bu internet ko'ra oladigan manzil emas va SaaS API'ga ketayotgan chiquvchi so'rovning manbasi sifatida hech qachon ko'rinmaydi. Shu ijaraga asoslangan ruxsat ro'yxati yozuvi ishlamaydi, u sotuvchi jurnallarida ko'rinishini qancha kutsangiz ham.
Bo'lingan tunnel va majburiy tunnel yonma-yon
| 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 |
Faqat ikkinchi qator uzoq xizmat ko'radigan manzilni o'zgartiradi. Jadvaldagi qolgan hamma narsa chiqishni Azure ichida tekshirish yoki tarjima qilish kerak bo'lganda qabul qiladigan xarajat va operatsion yuzadir. Agar kimdir sizdan umumiy IP o'zgarishini so'rasa, u butun o'ng ustunni so'rayapti, mijozdagi kichik tuzatishni emas.
Biror narsani qayta qurishdan oldin nomlashga arziydigan oraliq variant bor. VNet ichidagi proxy yoki shlyuz VM sizga o'sha tomonga yo'naltirilishi mumkin bo'lgan ilovalar uchun boshqariladigan manba manzilini beradi, mijozning standart yo'lini siljitmasdan. Bu oddiy ko'rishni mahalliy qoldiradi va Azure'dan bitta API chaqiruvi kelishini talab qiladigan hamkorni ham qanoatlantiradi. Talab haqiqatan barcha trafikka tegishli bo'lsa, u muvaffaqiyatsiz bo'ladi, chunki proxy sozlamasini e'tiborsiz qoldirgan har narsa baribir mahalliy chiqadi.
Tunnelni standart yo'lni olib o'tishga majbur qiling
Virtual tarmoq shlyuzida mijozning barcha internet trafigini tunnelga yo'naltirishning qo'llab-quvvatlanadigan usuli point-to-site konfiguratsiyasiga moslashtirilgan yo'llar qo'shishdir. Ikki yarim butun IPv4 maydonini qamrab oladi va har biri mahalliy standart yo'ldan aniqroq, shu sababli mijoz hech narsani o'chirmasdan ularni afzal ko'radi:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Bu qator nusxa ko'chirish uchun to'liq emas, misol sifatida berilgan: avval Get-AzVirtualNetworkGateway bilan shlyuz obyektini oling va uni GWOBJ o'rniga qo'ying, ishga tushirishdan oldin SKU va joylashtirish modeli moslashtirilgan yo'llarni qabul qilishini tasdiqlang. Xuddi shu prefikslar portalda point-to-site konfiguratsiya sahifasida ko'rinadi, va agar shlyuzni hali skript qilmayotgan bo'lsangiz, ularni sozlash uchun xavfsizroq joy o'sha.
Bu prefikslarni o'zgartirish mijoz paketini yaroqsiz qiladi. VPN mijoz paketini qayta yuklab oling va qayta o'rnating, chunki yo'llar profil ichida yuradi. Eski profili bilan qayta ulanadigan mijoz eski yo'llar to'plamini saqlaydi, va unga hech qachon yetib bormagan o'zgarishni tuzatishda bir soat yo'qotishingiz mumkin.
Himoyalangan virtual WAN habida ekvivalent point-to-site shlyuziga bog'langan hab yo'llar jadvalidagi standart yo'l bo'lib, trafikni habdagi Azure Firewall oladi. Firewall internetga qaratilgan ulanishlarni o'zining umumiy IP-manzillariga tarjima qiladi va yangi chiqish manzili aynan shu tarjimadan keladi. Firewall bir nechta umumiy IPga ega bo'lsa, ularning har biri manba sifatida ko'rinishi mumkin, shu sababli ruxsat ro'yxati ularning barchasini o'z ichiga olishi kerak.
Yuqoridagi ikkala dizayn ham IPv4. Ikki /1 prefiksi IPv6 uchun hech narsa qilmaydi, va point-to-site IPv6 qo'llab-quvvatlashi shu qadar torki, tenglikni va'da qilishdan oldin kombinatsiyani sinab ko'rish kerak.
Avval yo'lni, keyin chiqishni tekshiring
Paketni qayta o'rnatib, qayta ulangandan so'ng mijoz ikki yarimni haqiqatan o'rnatganini tasdiqlang. Windows'da Get-NetRoute -DestinationPrefix 0.0.0.0/1 va 128.0.0.0/1 uchun xuddi shu so'rov tunnel interfeysini nomlashi kerak, route print esa ikkalasini asl standart yo'lingiz yonida ko'rsatadi. Linux'da ip route show ikki prefiksni sanab o'tishi kerak; aks holda profil ularni hech qachon olib o'tmagan.
Keyin mijozdan umumiy manzilni qayta tekshiring va xuddi shu ulanish uchun firewall jurnalini o'qing. Manba tarjima qilingan port bilan firewallning umumiy IPsi bo'lishi kerak. Ikki yo'l mavjud bo'lsa ham mahalliy chiqadigan mijoz paketlar Azure'ga yetib, boshqa yo'l bilan chiqqanini bildiradi: shlyuz quyi tarmog'idagi foydalanuvchi belgilagan yo'l, o'zi mahalliy tarmoqqa majburiy tunnelda bo'lgan firewall yoki oqimni tarjimadan oldin tashlaydigan siyosat.
Xuddi shu sessiyada bitta xususiy manzilni qayta sinab ko'ring. O'zgarishdan keyin javob berishni to'xtatgan sakrash hosti yangi prefikslar nimanidir siqib chiqarganining odatiy belgisidir: avval e'lon qilingan torroq mahalliy yo'l yoki endi xususiy zonalaringiz uchun yo'naltiruvchisi yo'q rezolverga ketayotgan nom yechimi.
Bo'lingan tunnelni qachon tinch qoldirish kerak
Agar maqsad faqat xususiy API, xususiy endpoint yoki ichki administrator sahifasiga yetish bo'lsa, standart xatti-harakat arzonroq va tinchroq. Majburiy tunnel firewall soatlari va ma'lumotlarni qayta ishlash to'lovlarini, uzunroq yo'lni va har bir mijoz oqimi muvaffaqiyatsiz bo'lishi mumkin bo'lgan yana bir joyni qo'shadi. U sizni qiziqtirgan yagona manzildan ancha ko'proq trafikni ham ushlaydi.
Unga talab chiqish nuqtai nazaridan aytilganda murojaat qiling: hamkor barqaror Azure manzilini ko'rishi kerak, xavfsizlik ulanishlarning jurnalga olinishi va tekshirilishini xohlaydi yoki ma'lumotlar bitta boshqariladigan nuqtadan chiqishi kerak. Shunda ham dizayn har bir foydalanuvchiga umumiy chiqish beradi, shu sababli foydalanuvchi bo'yicha javobgarlik manba manzilidan emas, ilovadagi shaxsiyatdan kelishi kerak.
O'zgarishni yopishdan oldin to'rt narsani tasdiqlang: o'rnatilgan mijoz paketi yangi, ikki /1 yo'l tunnel interfeysida, xususiy manzil hali ham javob beradi va uzoq xizmat jurnali firewall manzilini ko'rsatadi.