Azure Point-to-Site VPN niyə ictimai IP-ni dəyişmir

Windows noutbukda Azure VPN müştərisini qoşuram, ünvan-əkssəda səhifəsini açıram və ev routerimin verdiyi ictimai ünvanın eynisini görürəm. Bu arada 10.20.0.4-dəki jump box cavab verir və özəl endpoint adı həll olunur, yəni tunel sınmayıb. Point-to-Site şlüzü məhz default konfiqurasiyasının dediyini edir: özəl prefiksləri daşıyır və qalan hər şeyi lokal linkdə buraxır. Azure-a məxsus çıxış ünvanı almaq marşrut dizaynının dəyişməsidir, təmir deyil.

Şlüz default olaraq nə elan edir

Şlüz virtual şəbəkə ünvan məkanı üçün marşrutlar, həmçinin şlüz tranzitinə icazə verilən peer şəbəkələr və site-to-site bağlantısı və ya BGP üzərindən öyrənilən yerli prefiksləri ötürür. Bu çoxluqda 0.0.0.0/0 yoxdur. Əməliyyat sisteminiz default marşrutunu Wi-Fi və ya Ethernet üzərində saxlayır, ona görə ictimai API-yə gedən paket heç vaxt tunelə daxil olmur.

Müştərinin tunel daxilində aldığı ünvan Point-to-Site hovuzundan özəl icarədir. O, müştərini VNet-dəki resurslar üçün tanıdır; internetin görə biləcəyi ünvan deyil və SaaS API-yə gedən çıxış sorğusunun mənbəyi kimi heç vaxt görünməyəcək. Həmin icarə üzərində qurulmuş allowlist qeydi nə qədər gözləsəniz də işləyə bilməz, çünki o, satıcı jurnallarında heç vaxt görünməyəcək.

Split tunnel və məcburi tunelləşdirmə yan-yana

Yalnız ikinci sətir uzaq xidmətin gördüyü ünvanı dəyişir. Cədvəldəki qalan hər şey çıxışın Azure daxilində yoxlanılmalı və ya tərcümə edilməli olduqda qəbul etdiyiniz xərc və əməliyyat səthidir. Əgər kimsə sizdən ictimai IP-nin dəyişməsini istəyirsə, o, bütün sağ sütunu istəyir, müştəridə kiçik düzəliş deyil.

Hər şeyi yenidən qurmazdan əvvəl adlandırmağa dəyən bir ara variant var. VNet daxilində proxy və ya şlüz VM-i, ona yönəldilə bilən tətbiqlər üçün nəzarətli mənbə ünvanı verir və müştərinin default marşrutunu tərpətmir. Bu, normal gəzintini lokal saxlayır və yalnız bir API çağırışının Azure-dan gəlməsini istəyən tərəfdaşı yenə qane edir. Tələb həqiqətən bütün trafikə aid olduqda isə uğursuz olur, çünki proxy parametrini nəzərə almayan hər şey yenə lokal çıxır.

Tunelin default marşrutu daşımasını təmin edin

Virtual şəbəkə şlüzündə bütün müştəri internet trafikini tunelə yönəltməyin dəstəklənən yolu Point-to-Site konfiqurasiyasına fərdi marşrutlar əlavə etməkdir. İki yarım bütün IPv4 məkanını əhatə edir və hər biri lokal default marşrutdan daha dəqiqdir, ona görə müştəri heç nə silmədən onlara üstünlük verir:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Bu sətir kopyala-yapışdır üçün tam deyil, nümunədir: əvvəlcə Get-AzVirtualNetworkGateway ilə şlüz obyektini götürün və GWOBJ yerinə onu qoyun, işə salmazdan əvvəl SKU və yerləşdirmə modelinin fərdi marşrutları qəbul etdiyini təsdiqləyin. Eyni prefikslər portaldakı Point-to-Site konfiqurasiyası səhifəsində də görünür; şlüzü artıq skriptlə idarə etmirsinizsə, onları təyin etmək üçün daha təhlükəsiz yer orasıdır.

Həmin prefiksləri dəyişmək müştəri paketini etibarsız edir. VPN müştəri paketini yenidən endirin və quraşdırın, çünki marşrutlar profil daxilində gedir. Köhnə profili ilə yenidən qoşulan müştəri köhnə marşrut dəstini saxlayır və ona heç vaxt çatmayan dəyişikliyi düzəltməyə bir saat itirə bilərsiniz.

Qorunan virtual WAN hub-da ekvivalent Point-to-Site şlüzü ilə əlaqələndirilmiş hub marşrut cədvəlində default marşrutdur, trafiki isə hub-dakı Azure Firewall götürür. Firewall internetə gedən bağlantıları öz ictimai IP ünvanlarına tərcümə edir və yeni çıxış ünvanı məhz bu tərcümədən gəlir. Firewallun bir neçə ictimai IP-si olduqda, onlardan hər hansı biri mənbə kimi görünə bilər, ona görə allowlist hamısını saxlamalıdır.

Yuxarıdakı hər iki dizayn IPv4-dür. İki /1 prefiksi IPv6 üçün heç nə etmir və Point-to-Site IPv6 dəstəyi o qədər dardır ki, bərabərliyə zəmanət verməzdən əvvəl kombinasiyanı sınaqdan keçirməlisiniz.

Əvvəlcə marşrutu, sonra çıxışı yoxlayın

Paketi yenidən quraşdırıb qoşulduqdan sonra müştərinin yarımları həqiqətən quraşdırdığını təsdiqləyin. Windows-da Get-NetRoute -DestinationPrefix 0.0.0.0/1 və 128.0.0.0/1 üçün eyni sorğu tunel interfeysini göstərməlidir, route print isə hər ikisini orijinal default-unuzun yanında göstərir. Linux-da ip route show iki prefiksi sadalamalıdır; sadalamırsa, profil onları heç vaxt daşımamışdır.

Sonra müştəridən ictimai ünvanı yenidən yoxlayın və həmin bağlantı üçün firewall jurnalını oxuyun. Mənbə tərcümə olunmuş portla firewallun ictimai IP-si olmalıdır. Hər iki marşrut mövcud olduğu halda hələ də lokal çıxan müştəri paketlərin Azure-a çatdığını və başqa yolla çıxdığını bildirir: şlüz alt şəbəkəsində istifadəçi təyin etdiyi marşrut, özü məcburi tunellə yerli şəbəkəyə yönəlmiş firewall, ya da axını tərcümədən əvvəl atan siyasət.

Həmin sessiyada bir özəl təyinatı yenidən sınayın. Dəyişiklikdən sonra cavab verməyi dayandıran jump host adətən yeni prefikslərin nəyisə sıxışdırdığının əlamətidir: ya əvvəl elan olunan daha dar yerli marşrutu, ya da indi özəl zonalarınız üçün forwarder-i olmayan resolverə gedən ad həllini.

Split tunnel-i nə vaxt toxunmadan buraxmalı

Məqsəd yalnız özəl API-yə, özəl endpointə və ya daxili admin səhifəsinə çatmaqdırsa, default davranış daha ucuz və daha səssizdir. Məcburi tunelləşdirmə firewall saatları və məlumat emalı xərcləri, daha uzun yol və hər müştəri axınının uğursuz ola biləcəyi daha bir yer əlavə edir. O, həm də narahat olduğunuz tək təyinatdan qat-qat çox trafik tutur.

Ona tələb çıxış baxımından ifadə olunanda müraciət edin: tərəfdaş sabit Azure ünvanı görməlidir, təhlükəsizlik bağlantıların jurnalaşdırılmasını və yoxlanmasını istəyir, ya da məlumat bir nəzarətli nöqtədən çıxmalıdır. Onda belə dizayn hər istifadəçiyə ortaq çıxış verir, ona görə istifadəçi üzrə məsuliyyət mənbə ünvanından deyil, tətbiqdəki kimlikdən gəlməlidir.

Dəyişikliyi bağlamazdan əvvəl dörd şeyi təsdiqləyin: quraşdırılmış müştəri paketi yenidir, iki /1 marşrutu tunel interfeysindədir, bir özəl təyinat hələ də cavab verir və uzaq xidmətin jurnalı firewall ünvanını göstərir.