Access Server'da ağ geçidi kullanıcısı: istemcinin şube LAN'ını yönlendirme

Bir OpenVPN istemcisinin tünel adresine ping atabilir ve yine de arkasındaki LAN'da hiçbir ana bilgisayara ulaşamazsınız. Access Server istemciye VPN havuzundan bir adres verir ve havuz adresi sunucunun kendisine ait bildiği tek şeydir. Şube öneki ayrıca bildirilmesi gereken bir olgudur ve o zaman bile şubenin bir ileticiye, merkezin bir dönüş yoluna ihtiyacı vardır. Yanlış yere yazılan yol hiçbir şeyi değiştirmez.

İki adres, iki farklı sahiplik iddiası

Bir istemci bağlandığında Access Server ona yapılandırılmış VPN havuzundan bir adres atar, örneğin 10.90.0.0/24. Bu atama tek bir ana bilgisayar için kiralamadır. Bağlantıda aynı istemcinin 10.60.0.0/24 önünde de durduğuna dair bir şey yoktur ve sunucu tahmin etmez: bir LAN öneki ancak yönetici bildirirse belirli bir istemci üzerinden erişilebilir.

Bu yüzden başka bir makinedeki statik yol işe yaramaz. Yol, 10.60.0.0/24'ü bu adrese gönder der, ancak adres hiçbir zaman ağ geçidi olarak işaretlenmemiş bir istemciye aitse sunucunun paketleri oraya teslim etmek için bir nedeni yoktur ve istemcinin yığını onları atabilir. Bildirim ve yol aynı mekanizmanın iki yarısıdır.

Ağ geçidi ayarının kurduğu şey

Admin Web UI'de bildirim bir kullanıcı özelliğidir: connector kullanıcısında Configure VPN gateway seçeneğini açın ve gerçek şube önekini Network on the VPN client side alanına girin. Bu kullanıcı diğerleri gibi kimlik doğrular, bu yüzden denetimsiz bir cihaza uygun bir kimlik bilgisi ilkesine ihtiyaç duyar ve otomatik oturum açma profili bir sırdır.

Sunucu öneki o istemcinin havuz adresi üzerinden erişilebilir sayar ve Access Controls altındaki yönlendirme yapılandırması diğerlerine ne söyleneceğine karar verir: sıradan istemcilere gönderilen yollar ve merkez ağlarından istemci adreslerine giden trafiğe izin veren kurallar. Şubeye ulaşması gereken ağlar için yönlendirmeyi açın ve izin listesini kısa tutun.

Oluşturulan dosyaya yapıştırılan Community tarzı bir direktif bu modelde yer almaz. Ürün gönderdiği yönlendirme tablosunun sahibidir; elle düzenlenen satırın üzerine yazılır veya yok sayılır.

İki ağın dönüş yollarını tamamlayın

Somut plan: merkez 10.40.0.0/24, şube 10.60.0.0/24, VPN havuzu 10.90.0.0/24 ve Access Server merkez tarafında özel bir adreste. Yönlendiricinin şube öneki ve havuz için yollara ihtiyacı vardır. Bunlar olmadan yanıt varsayılan ağ geçidinden çıkar, bu da yarı açık bağlantıyı oluşturur.

Şubede connector kendisine adreslenmemiş paketleri iletmelidir: işletim sisteminde IP iletimi ve tünel ile LAN arayüzleriyle sınırlı izin; Linux'ta net.ipv4.ip_forward=1 ile forward zinciri kuralları, Windows'ta routing and remote access. Ardından ana bilgisayarların dönüş yoluna ihtiyacı vardır: ya connector onların varsayılan ağ geçididir ya da mevcut ağ geçidi belirli yollar taşır.

Connector'ın yönlendirme tablosu şube LAN'ındaki her ana bilgisayarı yeniden yapılandırmaz. Ana bilgisayarlar başka bir yönlendiriciyi gösteriyorsa dönüş yolları oraya aittir ve o, gördüğü kaynak adresin yerel alt ağda bir komşu olmadığını kabul etmelidir.

Hatayı yol olarak okuyun

Belirli bir sırayla test edin. Önce Access Server'dan şube ana bilgisayarına izinli hizmet, sonra merkezin sıradan ana bilgisayarından aynı hizmet, sonra ilke izin veriyorsa ters yön. Birincisi geçip ikincisi başarısız olursa sorun gönderilen yollar veya erişim kurallarıdır. İkisi de geçip yanıt gelmiyorsa şubedeki iletimi ve merkezdeki dönüş yolunu inceleyin.

Ana bilgisayar güvenlik duvarı bir sonraki şüphelidir, çünkü yönlendirilmiş erişimde hedef kaynak olarak merkez veya havuz adresini görür. Yerel alt ağ için yazılmış bir kural eşleşmez.

İki tasarım daha fazlasını gerektirir. Çakışan önekler hedefi belirsizleştirir ve yeniden numaralandırma gerektirir; kümelenmiş Access Server her düğümün connector'a çalışan bir yolu olmasını gerektirir. Değişiklikleri olağan kaydetme yolundan uygulayın, connector'ı yeniden bağlayın ve iki uçtan doğrulayın.

Access Server site-to-site öğreticisi aynı ayarları ürün sırasıyla listeler.