PPP tabanlı bir VPN'den varsayımlarını kopyalamadan geçiş

Bir VPN geçişi, kullanıcılar, hedefler, ad çözümlemesi ve hata davranışı hâlâ doğru olduğunda tamamlanır; yeni istemci yeşil bir simge gösterdiğinde değil. Eski PPP tabanlı kurulumlar hiç yazılmamış varsayımlar taşır: tek kimlik denetimi işlevi de gören ortak bir sır, güvenlik duvarının izin listesinde tuttuğu sabit bir adres havuzu ve sunucunun gönderdiği bir DNS soneki. Bu varsayımları envanterlemeden protokolü değiştirmek, el sıkışmayı tamamlayan bir tünel ve var olmayan bir sınır üretir. Aşağıdaki sıra benim kullandığım sıradır ve son adım ekiplerin atladığı adımdır.

Adım 1: eski bağlantının ne sağladığını envanterleyin

Envanter akılda tutulmaz, yazılır. Desteklenen istemcileri, kimlik doğrulama rollerini, adres havuzlarını, korunan ağları, DNS gereksinimlerini ve her kullanıcı grubunun ihtiyaç duyduğu hizmet izinlerini kaydedin.

L2TP/IPsec için iki katmanı açıkça ayırın. IPsec eşinin kimliği makineleri doğrular; PPP kullanıcıyı doğrular, genellikle CHAP veya MSCHAPv2 ile.

Eski kurulumlar varsayımlarını tam da bu ayrımda saklar. Her istemcinin paylaştığı önceden paylaşılmış anahtar bir cihazı değil bir grubu doğrular ve çoğu zaman hiç değiştirilmiş tek şey odur. PPP hesabı gerçek kullanıcı başına denetimse bunu söyleyin, çünkü yerine geçen çözüm bu denetimi paylaşılan bir dize olmayan bir şeyle yeniden üretmelidir. Sabit kaynak adresleri ve yerel ağ istisnalarını da not edin, çünkü bunlar kimsenin bozulana kadar belgelemediği bağımlılıklardır.

Adım 2: yerine geçen çözümü bilinçli tasarlayın

Yerine geçen çözümü seçmek gereksinimden gereksinime eşlemedir: kuruluşun desteklediği bir protokol ve bakımı sürdürülen bir istemci, ve her kimlik ve erişim gereksinimi gerçek bir mekanizmaya oturur. Ortak bir sır otomatik olarak cihaz başına anahtar veya sertifikaya eşit değildir ve kullanıcı başına PPP hesabı cihaz sertifikasına eşit değildir.

Adres aralıklarını her şeyden önce koordine edin, çünkü ev veya ofis LAN'ıyla çakışan bir yedek havuz, şifre gücüyle hiçbir ilgisi olmayan bir arıza yaratır. Havuzu eski hizmet için oluşturduğunuz aynı listeye ve yeni istemcinin varsayılan kabul ettiği şeylere karşı kontrol edin. Korumalı ağlar için dönüş yönlendirmesini doğrulayın ve yeni istemcinin eskisinin gönderdiği DNS sonekini gönderebildiğini veya belgeleyebildiğini doğrulayın. Bu iki madde, protokol değişikliğinden daha fazla geçiş kaydı üretir.

Adım 3: aşamalı uygulayın ve hem izni hem reddi doğrulayın

Temsili bir kullanıcı ve temsili bir uygulamayla uygulayın. Teste özel DNS çözümlemesini de katın, çünkü bir adrese ulaşan ama iç adı çözemeyen tünel yalnızca yarı geçirilmiştir. Beklenen kullanılamaz durumu da katın: tünel düştüğünde ne olmalı ve istemci bunu zorluyor mu.

Ardından reddedilmiş kalması gereken bir hedefi test edin. Geniş bir geçici izin kuralı yeni tüneli sağlıklı gösterebilirken eski hizmetin uyguladığı yetkilendirme sınırını sessizce kaldırır ve kimse bir denetime kadar fark etmez. İzin ve ret sonuçlarını yan yana karşılaştırın, aynı istemciden, aynı oturumda. Her iki sütun da tasarımla eşleşene kadar eski hizmeti çalışır tutun.

Yönetici erişimini taşımadan önce, değiştirdiğiniz tünele bağlı olmayan yetkili bir kurtarma yolunuz olduğunu doğrulayın.

Adım 4: eski kimliği kullanımdan kaldırın

Eski kimliği doğru şekilde kullanımdan kaldırmak, eskimiş kullanıcıları ve cihaz kimlik bilgilerini onlara sahip olan hizmet üzerinden iptal etmek, ardından hiçbir bağımlılık kalmadığında eski profilleri ve dinleyicileri kaldırmak demektir. Yerel bir dosyayı silmek başka yerdeki bir kopyayı iptal etmez ve eski ortak sırrı hâlâ kabul eden eski bir dinleyici, gözetimsiz bir kapıdır.

Bu noktada yavaşlamaya değer. Dizüstü bilgisayardaki kullanımdan kaldırılmış istemci profili iptal edilmiş kimlik bilgisi değildir; kimlik bilgisi sunucuda yaşar ve sunucu onu kabul etmeyi bırakana kadar geçerli kalır. Eski yapılandırmanın diğer kopyalarını arayın — test cihazları, unutulmuş bir telefon, birinin sakladığı bir kurulum dosyası — ve dinleyicinin kapatılmasını eski hizmetin gerçekten sona erdiği an olarak görün. O zamana kadar geçişin iki ön kapısı vardır.

Kabul kaydı, birinci adımdaki envanterin bir sütun eklenmiş halidir: yeni tasarımın her satır için ne yaptığı ve bunu nasıl doğruladığınız. Bu, protokol yükseltmesini kanıtlı bir hizmet gereksinimine dönüştürür.

Sonucu protokol adına değil hizmetin ihtiyaç duyduğu şeye bağlı tutun, çünkü eski varsayımların kopyalandığı modern bir protokol daha iyi bir çerçeveyle aynı risktir. RFC 3193 L2TP'nin IPsec üzerinden nasıl taşındığını açıklar; bu, iki katmanın her zaman ayrı kararlar olduğunu hatırlatan yararlı bir nottur. Envanterde açıklayamadığınız bir satır varsa durun ve ona neyin bağlı olduğunu bulun. Liste sıkıcı hale geldiğinde geçiş tamamlanır.