EC2 üzerinde Access Server tam tünel: tek bir onay kutusu neden yeterli değil

EC2 örneğinde kaynak ve hedef denetimini kapatmak, Access Server internet çıkışıyla ilgili sorulara en çok tekrarlanan yanıttır ve tek başına istemcileriniz için hiçbir şey yapmaz. Denetim bir AWS yönlendirme kısıtıdır: örneğin kaynağı veya hedefi kendi adresi olmayan paketleri kabul etmesini sağlar. İstemciye internet trafiğini tünelden göndermesini söylemez, yukarı yönlü bir rota oluşturmaz ve NAT eklemez. Efsane, onay kutusunun özelliğin kendisi olduğudur.

Denetim gerçekte neyi kontrol eder

Her EC2 ağ arayüzü kendisine yönlendirilmemiş trafiği atar; ancak örnek yönlendirici, NAT aygıtı veya VPN geçidi olarak çalışıyorsa ve siz bu denetimi kapatırsanız. Kapatmak yönlendirme izni verir. İzin yapılandırma değildir: örneğin hâlâ bir internet geçidine veya NAT aygıtına rotaya ihtiyacı vardır, VPC rota tablosunun hâlâ eşleşen girdiye ihtiyacı vardır, güvenlik grupları hâlâ akışa izin vermelidir ve sunucu hâlâ dönüş trafiğini çevirmeli veya yönlendirmelidir.

Herhangi bir şeyi değiştirmeden önce mevcut değeri aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck ile kontrol edin. Konsolda değiştirirseniz, bir istemci internete ulaşamadığı için değil, örnek başkaları için yönlendirdiği için değiştirin.

İstemcinin yönlendirme politikası Access Server aittir

Access Server 3 içinde Access Controls öğesini açın ve Internet Access and DNS bölümünü bulun. Internet Gateway seçimi tam veya bölünmüş tünel sunar; tam tünel istemciye varsayılan trafiğini VPN içine yönlendirmesini söyler, bölünmüş tünel internet trafiğini istemcinin yerel yolunda bırakır. Ürünün iş akışıyla kaydedin ve uygulayın, ardından test istemcisini yeniden bağlayın, çünkü politika bağlantı anında teslim edilir.

Eski sürümler farklı menüler kullanır ve bazı Community OpenVPN derlemelerinde eşdeğer denetim yoktur. Olmayan bir ekranı aramadan önce kurulu ana sürümü kontrol edin. Ardından istemcinin ne aldığını doğrulayın: tam tünel profili tünelden varsayılan rota kurmalıdır ve bölünmüş tünel profili bunu yapmamalıdır.

Tünelden sonra paketi izleyin

İstemci internet trafiğini tünele gönderdiğinde sunucu bunu yönlendirmeli ve genellikle çevirmelidir. Access Server kendi NAT ve yönlendirme kurallarını yönetir, bu yüzden oluşturulan dosyalara Community OpenVPN kuralları eklemek yerine etkin yapılandırmayı okuyun; yönetilmeyen kurallar bir sonraki ürün güncellemesinde üzerine yazılır veya çakışır. sudo iptables -t nat -L -n -v veya nftables eşdeğeri gerçekte neyin çevrildiğini gösterir.

AWS tarafı ayrı bir yoldur. Genel alt ağdaki örnek bir internet geçidine doğrudan ulaşır ve genel adresini veya elastik IP sini korur. Özel alt ağdaki örnek bir NAT geçidine veya NAT örneğine rota gerektirir ve NAT aygıtı kendi internet geçidi rotasına ihtiyaç duyar. İnternet geçidini VPC ye bağlamak tek başına hiçbir özel kaynağa genel dönüş adresi vermez, bu yüzden aynı Access Server kurulumu bir alt ağda çalışır ve diğerinde sessizce başarısız olur.

Örneğin alt ağıyla ilişkili rota tablosunu kontrol edin, yalnızca VPC nin ana tablosunu değil. Alt ağ ilişkileri ana tabloyu geçersiz kılar ve eski bir ilişki, çalışan bir yapılandırmanın yeniden oluşturmadan sonra durmasının yaygın bir nedenidir.

IP çıkışını ve DNS i ayırın

Aynı istemci uygulamasından önce adres değişmezini, sonra adı test edin. curl -4 https://checkip.amazonaws.com genel bir adres döndürürken ana makine adları başarısız olursa tünel ve NAT yolu çalışıyor demektir ve sorun DNS tedir: gönderilen çözümleyici, istemcinin çözümleyici durumu veya çözümleyiciyi engelleyen bir güvenlik grubu. Access Server DNS ayarları aynı Internet Access alanındadır, ancak farklı bir kod yolu izlerler.

Dönen adresi amaçladığınız çıkışla karşılaştırın. Örneğin genel adresi ise trafik örnek tarafından çevriliyordur; bir NAT geçidi adresi ise özel alt ağ yolu kullanılıyordur. İkisi de doğru olabilir. Çıkaramayacağınız şey, sunucudaki bir tarayıcının istemci yönlendirmesini kanıtladığıdır.

Tek bir onay kutusunun soruşturmayı kapatmasına izin vermeyin

IPv6 ayrı bir karardır. IPv4 için tam tünel politikası, IPv6 nın taşınıp taşınmadığı, engellenip engellenmediği veya sızıp sızmadığı hakkında hiçbir şey söylemez ve çift yığınlı bir istemci IPv4 tüneldeyken yerel IPv6 yolunu kullanmaya devam edebilir. Gerçekten önemsediğiniz adres ailesini test edin ve diğerinin devre dışı bırakılıp bırakılmayacağına açıkça karar verin.

Son olarak, bağlantı kesilmiş durumu test edin. Tam tünel seçimi bağlıyken yönlendirme politikasını tanımlar, tünel düştüğünde ne olduğunu değil. Gereksinim VPN dışına hiçbir trafiğin kaçmaması ise, bu bir kill-switch ve güvenlik duvarı sorunudur ve rota tablosundan çıkarım yapmak yerine kendi testini gerektirir.