Azure Point-to-Site VPN neden genel IP adresinizi değiştirmez

Azure VPN istemcisini bir Windows dizüstü bilgisayarda bağlıyorum, adres yankısı sayfasını açıyorum ve ev yönlendiricimin verdiği aynı genel adresi görüyorum. Bu sırada 10.20.0.4'teki atlama kutusu yanıt veriyor ve özel bir uç nokta adı çözümleniyor, yani tünel bozuk değil. Bir point-to-site ağ geçidi tam olarak varsayılan yapılandırmasının söylediğini yapıyor: özel önekleri taşıyor ve geri kalan her şeyi yerel bağlantıda bırakıyor. Azure'a ait bir çıkış adresi almak yönlendirme tasarımının değişmesidir, onarım değil.

Ağ geçidi varsayılan olarak ne duyurur

Ağ geçidi, sanal ağın adres alanı için yolları, ağ geçidi geçişine izin verilen eş ağları ve siteden siteye bağlantı ya da BGP üzerinden öğrenilen şirket içi önekleri gönderir. Bu kümede 0.0.0.0/0 yoktur. İşletim sisteminiz varsayılan yolunu Wi-Fi veya Ethernet üzerinde tutar, bu yüzden genel bir API'ye giden paket tünele hiç girmez.

İstemcinin tünel içinde aldığı adres, point-to-site havuzundan özel bir kiralamadır. İstemciyi VNet'teki kaynaklara tanıtır; internetin görebileceği bir adres değildir ve bir SaaS API'sine giden giden isteğin kaynağı olarak asla görünmez. Bu kiralamanın etrafına kurulmuş bir izin listesi girdisi, satıcı günlüklerinde görünmesini ne kadar beklerseniz bekleyin çalışamaz.

Bölünmüş tünel ve zorunlu tünelleme yan yana

Uzak bir hizmetin gördüğü adresi yalnızca ikinci satır değiştirir. O tablodaki diğer her şey, çıkışın Azure içinde denetlenmesi veya çevrilmesi gerektiğinde kabul ettiğiniz maliyet ve operasyonel yüzeydir. Biri sizden genel IP'yi değiştirmenizi istiyorsa, sağ sütunun tamamını istiyordur, istemcide küçük bir ayar değil.

Herhangi bir şeyi yeniden kurmadan önce adlandırılmaya değer bir ara seçenek var. VNet içindeki bir proxy veya ağ geçidi VM'i, ona yönlendirilebilen uygulamalar için denetlenen bir kaynak adresi verir; istemcinin varsayılan yolu yerinden oynamaz. Bu, normal taramayı yerelde tutar ve Azure'dan yalnızca tek bir API çağrısının gelmesini isteyen bir iş ortağını da tatmin eder. Gereksinim gerçekten tüm trafikle ilgiliyse başarısız olur, çünkü proxy ayarını yok sayan her şey yine de yerelden çıkar.

Tünelin varsayılan yolu taşımasını sağlayın

Bir sanal ağ geçidinde, istemcinin tüm internet trafiğini tünele yönlendirmenin desteklenen yolu point-to-site yapılandırmasına özel yollar eklemektir. İki yarım tüm IPv4 alanını kaplar ve her biri yerel varsayılan yoldan daha özgüldür, bu yüzden istemci hiçbir şey silmeden onları tercih eder:

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

Bu satır örnektir, kopyalamaya hazır değildir: önce Get-AzVirtualNetworkGateway ile ağ geçidi nesnesini alın ve GWOBJ yerine onu koyun, çalıştırmadan önce SKU ve dağıtım modelinin özel yolları kabul ettiğini doğrulayın. Aynı önekler portaldaki point-to-site yapılandırma sayfasında da görünür; ağ geçidini henüz betiklemiyorsanız bunları ayarlamak için daha güvenli yer orasıdır.

Bu önekleri değiştirmek istemci paketini geçersiz kılar. VPN istemci paketini yeniden indirip yeniden kurun, çünkü yollar profil içinde seyahat eder. Eski profiliyle yeniden bağlanan istemci eski yol kümesini korur ve ona hiç ulaşmamış bir değişikliği ayıklamak için bir saat kaybedebilirsiniz.

Güvenli bir sanal WAN merkezinde eşdeğeri, point-to-site ağ geçidine bağlı merkez yol tablosundaki varsayılan yoldur ve trafiği merkezdeki Azure Firewall alır. Güvenlik duvarı internete yönelen bağlantıları kendi genel IP adreslerine çevirir ve yeni çıkış adresi tam olarak bu çeviriden gelir. Bir güvenlik duvarının birden çok genel IP'si olduğunda, bunlardan herhangi biri kaynak olarak görünebilir, bu yüzden izin listesi hepsini içermelidir.

Yukarıdaki iki tasarım da IPv4'tür. İki /1 öneki IPv6 için hiçbir şey yapmaz ve point-to-site IPv6 desteği, eşitlik vaat etmeden önce birleşimi test etmeniz gerekecek kadar dardır.

Önce yolu, sonra çıkışı kontrol edin

Paketi yeniden kurup yeniden bağlandıktan sonra istemcinin iki yarımı gerçekten kurduğunu doğrulayın. Windows'ta Get-NetRoute -DestinationPrefix 0.0.0.0/1 ve 128.0.0.0/1 için aynı sorgu tünel arabirimini adlandırmalıdır ve route print ikisini de özgün varsayılan yolunuzun yanında gösterir. Linux'ta ip route show iki öneki listelemelidir; listelemiyorsa profil onları hiç taşımamıştır.

Ardından istemciden genel adresi yeniden kontrol edin ve aynı bağlantı için güvenlik duvarı günlüğünü okuyun. Kaynak, çevrilmiş bir bağlantı noktasıyla güvenlik duvarının genel IP'si olmalıdır. İki yol varken hâlâ yerelden çıkan bir istemci, paketlerin Azure'a ulaşıp başka bir yoldan çıktığı anlamına gelir: ağ geçidi alt ağında kullanıcı tanımlı bir yol, kendisi şirket içine zorunlu tünellenmiş bir güvenlik duvarı veya akışı çeviriden önce düşüren bir ilke.

Aynı oturumda bir özel hedefi yeniden test edin. Değişiklikten sonra yanıt vermeyi bırakan bir atlama ana bilgisayarı, yeni öneklerin bir şeyi ittiğinin olağan işaretidir; ya daha önce duyurulan daha dar bir yerel yol ya da artık özel bölgeleriniz için ileticisi olmayan bir çözümleyiciye giden ad çözümlemesi.

Bölünmüş tüneli ne zaman rahat bırakmalı

Amaç yalnızca özel bir API'ye, özel bir uç noktaya veya iç yönetim sayfasına ulaşmaksa varsayılan davranış daha ucuz ve daha sessizdir. Zorunlu tünelleme güvenlik duvarı saatleri ve veri işleme ücretleri, daha uzun bir yol ve her istemci akışının başarısız olabileceği bir yer daha ekler. Ayrıca önemsediğiniz tek hedeften çok daha fazla trafik yakalar.

Gereksinim çıkış açısından ifade edildiğinde ona başvurun: bir iş ortağı sabit bir Azure adresi görmeli, güvenlik bağlantıların günlüğe alınmasını ve denetlenmesini istiyor veya veriler tek bir denetlenen noktadan çıkmalı. O zaman bile tasarım her kullanıcıya ortak bir çıkış verir, bu yüzden kullanıcı başına hesap verebilirlik kaynak adresinden değil uygulamadaki kimlikten gelmelidir.

Değişikliği kapatmadan önce dört şeyi doğrulayın: kurulu istemci paketi yeni olan, iki /1 yolu tünel arabiriminde, özel bir hedef hâlâ yanıt veriyor ve uzak hizmetin günlüğü güvenlik duvarı adresini gösteriyor.