L2TP, GRE mi IPsec mi: oturumu hangi katman taşımalı?

L2TP, GRE ve IPsec aynı tasarım notuna girdiğinde iki soru birbirine dolaşır: hangi oturumu taşıyorum ve onu hangi katman koruyor? İlkinde yanılırsanız, aşağıdaki her şey kendi içinde tutarlı kalırken yanlış problem çözülür — kullanıcıların çevirmeli bağlanması gereken yere yönlendirilmiş bir kaplama kurulur ya da siteden siteye geçit yerine bir çevirmeli erişim yoğunlaştırıcısı konur. Aşağıdaki çalışma sayfası, biri cihaza giriş yapmadan önce bu ayrımı zorunlu kılar. Sırayla doldurun; her satır tek başına test edilebilen bir şeye dönüşür.

Protokol listesinden değil, oturumdan başlayın

PPP oturumu tutan uzak bir kullanıcı ile iki geçit arasındaki yönlendirilmiş kaplama, ikisi de sonunda IPsec'e sarılsa bile farklı ağ ilişkileridir. Birincisi kullanıcı başına bir bağlantıyı sonlandırır ve adres ataması, bir kişinin ya da cihazın kimlik doğrulaması ve bu kullanıcının hangi iç ağlara erişebileceğini belirten bir politika gerektirir. İkincisi, kimsenin çevirmeli bağlanmadığı siteler arasında paket iletir.

İkisinden hangisini kurduğunuzu belirten tek bir cümle yazın, sonra onu işletmek zorunda olan kişi gibi okuyun. Cümle 've' sözcüğüne ihtiyaç duyuyorsa ikisini birden kuruyorsunuz; çalışma sayfası, her birine yarım hizmet eden tek bir uzlaşma sütunu yerine iki sütuna ihtiyaç duyar. Bir kullanıcıdan söz edip adres havuzundan söz etmiyorsa, ya da bir öneki anıp iletime ilişkin politika vermiyorsa, cümle hâlâ eksiktir. İfade bürokratik gelse de, aksi hâlde bir yardım masası kaydının ortaya çıkaracağı tasarımı yakalamanın en ucuz yeridir.

Her katmana tam olarak bir görev verin

L2TPv2, PPP oturumlarını iki uç noktası arasında taşır. PPP bağlantı anlaşmasını ve anlaşıldığında kullanıcı kimlik doğrulamasını yürütür; L2TP hiçbir şifreleme eklemez, bu yüzden çıplak bir L2TP arka plan programı IPsec güvenlik ilişkisinin hiçbir parçasını uygulamaz ve yalnızca zaten güvendiğiniz bir bağlantının içinde yer alır.

GRE iki adres arasında bir kapsüllemedir. Ağ katmanı paketlerini mantıksal bir kaplama üzerinden taşır ve tek başına ne gizlilik ne de kimliği doğrulanmış bir eş kimliği sunar. Bu bir kusur değildir: başlık, iletim donanımında işlenmesi ucuz kalsın diye basit tasarlanmıştır. Sonuç, GRE'nin 'bu paketi iki adres arasında nasıl taşırım' sorusunu yanıtlaması ve başka hiçbir şeyi yanıtlamamasıdır — tam da ona sormanız gereken soru.

Böylece IPsec, trafiği seçen, eşleri kimlik doğrulayan ve koruması söyleneni şifreleyen katman olarak kalır. Neyi koruyacağı, uç noktaların gerçekte ürettiği kapsüllemeyle eşleşmesi gereken bir yapılandırma kararıdır, çünkü GRE dış adresi için yazılan politika, iç önekler için yazılandan farklı davranır. GRE belirtimi yükü, GRE başlığını ve dış teslim protokolünü görünür biçimde ayrı tutar ve politikanızın da aynı ayrımı yapması gerekir.

Yapılandırmadan önce paket yolunu yazın

Bir paket alın ve eklenen her başlığı eklendiği sırayla listeleyin, onu ekleyen cihazı da belirtin. Çevirmeli kullanıcı için bu genellikle IPsec içinde L2TP içinde PPP'dir; site kaplaması için GRE içinde iç IP paketi, IPsec içinde GRE. İki cihaz aynı başlığı ekliyorsa bir döngü ya da yinelenen tünel vardır ve hiçbir politika düzenlemesi bunu düzeltmez.

Aynı liste MTU'yu da belirler, çünkü kullanılabilir iç boyut ölçülen yol MTU'sundan az önce saydığınız başlıkların çıkarılmasıyla kalandır, başka bir şey değil. Bir forum gönderisinden sayı kopyalamayın: dış IP, UDP ve ESP yükünü toplayın, ardından GRE veya L2TP, geçerliyse PPP ekleyin ve gerçekten ölçtüğünüz yol MTU'sundan çıkarın. Yalnızca büyük aktarımlarda görünen belirtiler ya da kurulduktan sonra ilk büyük yanıtta ölen oturumlar genellikle bu toplamanın tahminle yapılmasına dayanır.

Her katmanı ayrı ayrı, dışarıdan içeriye doğru doğrulayın

Kontrolleri sırayla çalıştırın ve ilk başarısız olanda durun. Her satır farklı bir soruyu yanıtlar, bu yüzden bir hata tünelin bozuk olduğunu söylemek yerine çalışma sayfasının bir sütununu işaret eder.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Bir Cisco kutusunda eşdeğeri role bağlıdır ve tam sözdizimi platforma ve sürüme göre değişir: IPsec eşleri için show crypto session, GRE veya tünel arayüzü için arayüz sayaçları, çevirmeli rol için VPDN veya PPP doğrulaması. PPP'yi sonlandıran bir komut kümesi GRE desteği hakkında hiçbir şey kanıtlamaz, çalışan bir GRE arayüzü de PPP hizmeti hakkında hiçbir şey kanıtlamaz; bu yüzden şemadaki rolü değil gerçekten yapılandırdığınız rolü doğrulayın.

Her çıktıyı ait olduğu çalışma sayfası satırının yanına kaydedin. Arıza sürerken alınan notlar, sonradan bellekten yeniden çizilen bir topolojiden daha değerlidir.

Sökme sırasını belirleyin, sonra yeniden doğrulayın

Sökme işlemi bir nedenden dolayı ters sırada yürür: korunan trafiği, politikanın yazıldığı kapsüllemeyi kaldırmadan önce IPsec politikasından çıkarın, yoksa politika artık var olmayan bir arayüzü göstermeye devam eder ve sonraki yapılandırma yüklemesi ilgisiz görünen bir yerde başarısız olur. Linux'ta bu, tünel arayüzünden önce state ve policy girdilerini silmek anlamına gelir; bir yönlendiricide tünelden önce crypto map veya profile girdisini kaldırmak.

Yeniden kurulumdan sonra dört kabul gözlemini tek tek yineleyin: dış erişilebilirlik, kurulmuş bir IPsec ilişkilendirmesi, tasarım içeriyorsa kurulmuş bir PPP oturumu ve gerçek bir hedef adrese iç iletim. Tek bir yeşil ışık diğer üçünün kanıtı değildir ve bu boşluk üretimde en uzun yaşayan arızadır — ayakta, şifreli ve hiçbir şey iletmeyen bir tünel, çünkü iç rota hiç eklenmemiştir.

Doldurulmuş çalışma sayfasını cihaz yapılandırmasının yanında tutun. Dolduramadığınız her sütun, atanmış görevi olmayan bir katmandır ve atanmış görevi olmayan katman genellikle yığında olmaması gereken katmandır.