Şifre çözümünden sonra: VPN trafiğinizi ilk hangi politika görür

Bir VPN akışı kusursuz şifrelenmiş ve kusursuz kimlik doğrulanmış olsa bile kimsenin planlamadığı bir yere varabilir. Takılan kablo, iç paketi hangi kuralın işlediğini belirlemez; bunu politika kancası ve rota belirler. Bu nedenle raf şemasında aynı görünen iki tasarım tamamen farklı uygulamaya sahip olabilir. Aralarında seçim yapmak, çözülmüş akışı ilk gören denetimin adını koymakla başlar.

Porta göre değil, politika kancasına göre karar verin

Her VPN platformu iletmeden önce bir noktada çözülmüş trafiği değerlendirir ve o noktanın yapılandırmada bir adı vardır. Bir platformda grup ilkesi süzgecidir, diğerinde arayüz ilkesi ya da bölge çiftidir, yönlendirme yapan bir cihazda ise yalnızca forward zinciri olabilir. Kuralı kanca uygular, anahtar portu ise yalnızca kablonun bittiği yerdir. Kancayı bulmak ilk karardır, çünkü geri kalan her şey ona göre yerleşimdir.

Donanıma bakmadan önce akışı yazın: kaynak kim, nereye gidiyor, hangi protokol taşıyor ve hangi hizmete izin var. Sonra bu dört olgunun her birini uygulayan denetimi bulun.

İki yol, iki farklı uygulama öyküsü

İki biçim yaygındır ve her biri farklı bir gereksinim için doğru olabilir.

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

İlk biçim gerekli her şeyi ağ geçidinde uygulayabilir; yeter ki ilke o hedef için yazılmış olsun ve sunucunun etrafından dolaşan bir yolu olmasın. İkinci biçim bir sınır ekler, ama ancak rotalar ve ilke trafiği gerçekten oradan geçiriyorsa. Uç noktayla aynı segmentte oturan bir sunucu, hayal edilen ara atlamayı hiç izlemeyebilir. Şema niyeti gösterir, yönlendirme tablosu ne olduğunu gösterir.

Çizimle değil rota sorgusuyla doğrulayın. Paketin çıktığı arayüz ve seçtiği sonraki atlama, ikinci biçimin tasarlandığı gibi çalışıp çalışmadığını belirler.

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

Topolojiyi yalıtımdan ayırın

Bir alt ağı paylaşmak bir yeri güvenilmez yapmaz, özel bir geçiş de onu korumalı yapmaz. Belirleyen, gerçekte uygulanan kısıtlama, gerçekte olan yönlendirme ve her parçayı kimin yönettiğidir. Anahtar saymak bu üçünün hiçbiri hakkında bir şey söylemez. İlkeden ve rotadan karar verin, topoloji de kararı izlesin.

Trafik kümelerini de ayrı ele alın. Uzaktan erişim havuzları, saha-saha önekleri ve özel hat ağları tek bir cihazı paylaşıp yine de farklı kurallara ihtiyaç duyabilir, çünkü kimlikleri ve riskleri farklıdır. Bir küme için yazılan kural, adres planını paylaştıklarında diğerlerini sessizce kapsar.

Her yerleşim için arıza ve yönetimi denetleyin

Her yerleşimin bir arıza biçimi vardır ve faydalı soru bir bileşen durduğunda neyin hâlâ çalıştığıdır. Tek bir ölü cihaz üzerinde birkaç mantıksal arayüz bağımsız kurtarma sağlamaz ve aynı beslemeyi ya da aynı yöneticiyi paylaşan alt akıştaki bir güvenlik duvarı ikinci sınır değildir. Yönetim yolunun nereden geçtiğini sorun, çünkü yalnızca tünelden erişilebilen bir konsol hiçbir kurtarma yolu değildir; ssh [email protected] true tünelin dışından çalıştırmak, konsolun ona bağlı olmadığını kanıtlamanın en ucuz yoludur. Bir platformun grup ilkesi belgeleri süzgecini şifre çözümünden sonra ve şifrelemeden önceki trafiğe koyar; bu da her üründe aranması gereken tam da o adlandırılmış kancadır.

Her adayın arıza öyküsünü uygulama öyküsünün yanına yazın. Denetimde kazanıp kurtarmada kaybeden bir yerleşim bir takastır ve olay sırasında keşfedilmek yerine böyle kaydedilmelidir.

İzin verilen ve reddedilen akışla kabul edin

Onaylı bir test planıyla gerçek VPN kaynağından üç şeyi denetleyin: çalışması gereken uygulama, çalışmaması gereken kaynak ve yanıtın döndüğü yön. Ret, ilkenin devrede olduğunun kanıtıdır; izin verilen akış ise yalnızca bir yol olduğunu gösterir.

Seçilen yolu ve ilkenin sonucunu birlikte saklayın, çünkü yolsuz sonuç yeniden üretilemez ve sonuçsuz yol savunulamaz. Bu çift, hangi anahtarlama katmanının doğası gereği daha güvenli olduğuna dair herhangi bir iddiadan çok daha faydalıdır.