Tek bir AWS Client VPN oturumunun arkasındaki LAN: ne yönlendirilir

Dizüstü bilgisayar AWS Client VPN uç noktasına bağlanır, özel alt ağa ulaşır ve her şey sağlıklı görünür. Aynı LAN'daki masaüstü hiçbir yere ulaşamaz, oysa Linux ana makinesinin de bir köprü arayüzü vardır ve iki makine aynı kablodadır. Tünelde yanlış yapılandırılmış bir şey yoktur; eksik parça yönlendirmedir ve köprü yanıltıcı bir izdir.

Bir Client VPN oturumunu LAN'a genişletmek bir ağ geçidi rolüdür. Yönetilen bir hizmete uzatılmış bir Ethernet segmenti değildir.

Ana makine çalışıyor, LAN çalışmıyor

Linux makinesindeki tünel arayüzünün adresi Client VPN istemci CIDR'ı içindedir ve uç nokta VPC aralıkları için rotalar göndermiştir. O makinede yapılan bir istek yerel olarak üretilen trafiktir: bir rota seçer, tünelden çıkar ve yanıt alır. Bu yol hiçbir zaman yönlendirme koduna, LAN arayüzüne veya geçişi yöneten herhangi bir güvenlik duvarı kuralına dokunmaz.

Başka bir LAN cihazından gelen trafik farklı bir akıştır. LAN arayüzüne ulaşır, tünele işaret eden bir rotaya ihtiyaç duyar, yönlendirmenin açık olması gerekir, ona izin veren bir güvenlik duvarı gerekir ve yanıtın aynı ana makineden geri gelmesi gerekir. Dört koşul var ve çalışan dizüstü testi bunların hiçbirini kanıtlamıyor. Masaüstünden arıza tuhaf görünür: tünel açık, kimlik bilgileri geçerli ve hedef hiç yanıt vermiyor. Kusur ağ geçidinin yönlendirme yolunda yereldir, hizmette değil.

Her istemci ağ geçidi olamaz

AWS, Client VPN masaüstü uygulamasının IP yönlendirmeyi desteklemediğini, diğer istemcilerin destekleyebileceğini belirtir. Bu kısıtlama herhangi bir komut yazılmadan önce mimariyi belirler. Kullanılabilir tek istemci resmi masaüstü uygulamasıysa, LAN için yönlendirme yapan bir Linux ağ geçidi tamamlayabileceğiniz bir yapılandırma değildir ve hiçbir masquerading bunu değiştirmez.

Yedek istemcinin uç noktanın kimlik doğrulama yöntemine ve uygulamayı düşündüğünüz politikaya da uyması gerekir. Sertifika tabanlı, dizin tabanlı ve SAML destekli uç noktalar aynı istemci yapılandırmalarını kabul etmez ve kimlik doğrulaması yapıp gönderilen rotaları yok sayan üçüncü taraf bir istemci bir iyileştirme değildir.

İstemci seçimini tasarım incelemesinin bir parçası olarak ele alın. LAN yönlendirme modelinin hiç mevcut olup olmadığını ve uç noktanın ağ geçidinin arkasındaki her cihaz için hangi kimliği gördüğünü belirler. İstemciyi ve test edildiği uç nokta yapılandırmasını kaydedin. Altı ay sonraki bir istemci değişikliği tasarımın varsaydığı yeteneği sessizce kaldırabilir.

LAN'ı tünele yönlendirin ve çevirin

Desteklenen bir istemci yerindeyse geri kalan olağan ağ geçidi işidir. LAN cihazlarının VPC aralığı için Linux ana makinesine işaret eden bir rotaya ihtiyacı vardır ve ana makinenin yönlendirmesi açık olmalıdır. VPC'nin trafiği rastgele bir LAN adresi olarak değil bağlı istemci olarak görmesini istiyorsanız, çıkışta kaynağı çevirin.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Kuralı yukarıdaki gibi tünel arayüzü ve VPC aralığıyla sınırlayın, ana makinenin yönlendirdiği her şeyi masquerade etmek yerine. Dar kural üzerinde düşünmek daha kolaydır ve özgün kaynak adresini koruması gereken trafiği sessizce değiştirmez.

Mümkünse LAN rotasının otomatik gelmesini sağlayın: bir DHCP seçeneği, bir yönlendirici duyurusu veya LAN'ı yöneten şeyin gönderdiği statik bir rota. Yalnızca bir test makinesinde bulunan bir rota, başka biri denediği anda tasarımı bozuk gösterecektir.

Yanıtın da bir yolu olmalı

İstek VPC'ye ulaştığında, yanıt aynı çeviri durumlarından geri gelmeli ve ağ geçidinde LAN rotasını bulmalıdır. Bu kısım genellikle masquerade kuralı yerindeyken çalışır, çünkü eşleme onu yapan ana makinede yaşar. VPC tarafında yanıtı başka yere gönderen bir rota olduğunda bozulur; bu yüzden hem istemci CIDR rotası hem de uç noktadaki alt ağ ilişkilendirmesi önemlidir.

Yalnızca ping'e değil, sayaca bakın. Sıfır paketli bir masquerade kuralı size isteğin tünel arayüzüne hiç ulaşmadığını söyler, bu da LAN rotasına veya istemcinin kendi yönlendirme tablosuna işaret eder. Paketi olan ama yanıtı olmayan bir kural VPC tarafına, yetkilendirme kurallarına veya çevrilen kaynağı kabul etmeyen bir güvenlik grubuna işaret eder. Bir şeyi değiştirmeden önce iki yönü de okuyun, çünkü yalnızca bir tarafta büyüyen sayı yavaş bir yol değil tek yönlü bir yoldur.

Uç noktanın yönetilen bir hizmet olduğunu unutmayın. Düzenlenecek bir sunucu yapılandırma dosyası ve eklenecek bir client-config yönergesi yoktur, bu nedenle özel istemci alt ağ rotaları olan kendi kendine yönetilen bir OpenVPN sunucusu için yazılmış talimatlar aktarılmaz. AWS'de kaldıraçlar alt ağ ilişkilendirmesi, yetkilendirme kuralları ve VPC'nin yönlendirme tablolarıdır.

Paylaşılan kimlik, politikanın yanıtlaması gereken kısımdır

Ağ geçidinin arkasındaki her cihaz ağ geçidinin VPN oturumunu kullanır. Uç noktanın yetkilendirme kuralları bir kullanıcıya veya gruba erişim verir ve hizmetin bakış açısından o oturumda tam olarak bir kullanıcı vardır. Yerel yönlendirme bu kimliği cihaz başına kimlik doğrulamasına çoğaltmaz ve cihaz duruş denetimlerini köşedeki yazıcıya kadar genişletmez.

Bu kabul edilebilir olabilir veya tasarımın reddedilme nedeni olabilir. VPC kaynaklarının kimin aradığına dair ne varsaydığına bağlıdır. Yetkilendirme modeline uyan paylaşılan bir kimlik sorun değildir; tek bir kimliği doğrulanmış oturumu sessizce tüm LAN erişimine dönüştüren bir kimlik yazılmayı bekleyen bir bulgudur.

Gereksinim gerçekten tüm bir sahayı bir VPC'ye bağlamaksa, uzaktan erişim istemcisini genişletmeden önce desteklenen bir saha-sahaya tasarımı karşılaştırın. Anlam farklıdır ve VPC'nin LAN'a bağlantı başlatması gerektiğinde NAT'lanmış bir istemci oturumu saha bağlantısı için zayıf bir yedektir.

İstemciye, rotaya, çeviriye ve kimlik hikâyesine bu sırayla karar verin. Her biri sonrakini kısıtlar ve sıra, ana makinenin neden çalıştığını ama LAN'ın çalışmadığını açıklar.