Bir forum başlığında, ifconfig-noexec tünel açıldığında SSH oturumunu canlı tutan düzeltme olarak sunulur. Bu gerekçe, seçeneğin gerçekte neye dokunduğunu kontrol edene kadar makul görünür. Şunu engeller: OpenVPN tünel arayüzünün adresini yapılandıramaz ve bu değerleri onun yerine betiklere verir; yönetim bağlantınıza gelen yanıtların nereye gittiği hakkında hiçbir şey söylemez. Tersine inanmak, kullanılabilir adresi olmayan bir tünel ve yine de ölen bir SSH oturumu üretir.

Seçenek gerçekte neyi devrediyor

Varsayılan olarak istemci tünel aygıtını kaldırır ve sunucunun ona verdiği yerel ve uzak adresleri atar. ifconfig-noexec ayarlandığında bu adım atlanır ve anlaşılan değerler betik ortamına aktarılır, böylece başka bir şey bunları uygulayabilir.

Sahiplik el değiştirir. Onun yerine hiçbir şey uydurulmaz.

Yani seçeneğin yanıtladığı soru arayüzü kimin yapılandırdığıdır ve yanıtlamadığı soru, paketlerin size nasıl geri döndüğüdür. Bu ikisini ayrı tutun, yoksa adresi olmayan bir arayüzü telafi etmek için bütün akşamı rota düzenleyerek geçirirsiniz.

Farklı işleri olan üç benzer seçenek

Adlar tek kelimeyle ayrıldığı ve belirtiler birbiriyle örtüştüğü için bu aileyi karıştırmak kolaydır. Herhangi birini seçmeden önce her birinin neyi bastırdığını okuyun.

OptionWhat stops happening
ifconfig-noexecOpenVPN's own tunnel-address configuration; values go to scripts instead
route-noexecAutomatic route addition and removal; route details go to a script
route-nopullServer-pushed routes and related options such as DNS are rejected

Bunlar tek tek anlaşılması gereken alternatiflerdir, birlikte yapıştırılacak bir küme değil. Adres yapılandırmasını bastırmak rota değişikliklerini, güvenlik duvarı kurallarını veya DNS taşıyan itilen seçenekleri bastırmaz. Devredilen bir betik de rotaları değiştirmekte özgürdür ve bu, kaçınmak yerine devrettiğiniz bir karardır.

Bir sağlayıcı istemcisi motoru sarmalıyorsa, profiline düşük düzeyli bir yönerge atıp sarmalayıcının buna saygı duymasını ummak yerine desteklenen entegrasyonunu kullanın. Sarmalayıcılar bağlanırken profili sık sık yeniden üretir, bu yüzden elle yapılan düzenleme hata vermeden kaybolur. Bir akşamı dosyaya harcamadan önce istemcinin ayarlarını nerede tuttuğunu kontrol edin. Bu, tablodaki her satır için geçerlidir, yalnızca geldiğiniz satır için değil.

Korumak istediğiniz SSH oturumu

Bir SSH bağlantısının kaynak adresi, hedef adresi ve yanıt yolu vardır. Tam tünel varsayılanını yeni kurmuş bir sunucuda, genel adresinize giden yanıt tünelle eşleşir ve VPN geçidi onu düşürür.

Tünel arayüzünün adres yapılandırmasında hiçbir şey bunu değiştirmez.

Bunu düzelten şey, yönetim adresiniz için tünelden önceki geçit üzerinden daha belirli bir rota ya da o trafiği yönlendiren bir ilke kuralı, ayrıca ana makinenizin uyguladığı filtre ayarlarıdır. İki sorun bazen birlikte görünür ve bu yüzden biri diğerinin çaresi sanılır. Bunları ayrı ayrı test edin: tüneli seçenek olmadan kaldırın, arayüz adresine ve yanıt yoluna bakın, sonra ikisinden hangisinin gerçekten bozuk olduğuna karar verin.

Devredilen bir betik neyi üstlenmeli

Arayüzü gerçekten başka bir sahibin yapılandırmasını istiyorsanız işi sıralayın: yerel ve uzak adresi uygulayın, aygıtı kaldırın, sökme sırasında adreslemeyi geri yükleyin veya kaldırın ve yeniden bağlandıktan sonra aynısını tekrar yapın. Başarılı bir oturumun değerleri sabit kodlanmamalıdır, çünkü sunucu bir dahaki sefere başka bir çift verebilir.

İstemcinin dışa aktardığı ortam değişkenleri o iş için desteklenen tek girdidir.

env | grep -E '^ifconfig_|^route_'

Herhangi bir route-up betiğinin içinde bu değişkenler kullanılabilir; bir cron işinden veya elle çalıştırılan kabuktan kullanılamaz. Sürümünüzün hangi yaşam döngüsü kancasını kullandığını ve kancanın arayüzü değiştirmek için yeterli ayrıcalıkla çalıştığını doğrulayın, çünkü istemci çoktan ayrıcalıksız bir kullanıcıya inmiş olabilir.

Tek bir oturumu değil, tüm yaşam döngüsünü test edin

Tüneli kaldırın, aygıttaki adresi kontrol edin, sonra yeniden bağlanın ve tekrar kontrol edin. Bir kez çalışıp ikinci denemede başarısız olan yapılandırma genellikle devredilen adımın yalnızca ilk bağlantıda çalıştığı anlamına gelir.

Sonra iki kabul ölçütünü birlikte test edin: amaçlanan yönetim yolu üzerinden yeni bir SSH bağlantısı çalışır ve izin verilen uygulama tüneli doğru kullanır.

Tünelin adresi yokken eski bir SSH oturumunun tesadüfen hayatta kalması başarı değildir ve kimse işi üstlenmediğinde bu seçeneğin ürettiği durum tam olarak budur. Önce arayüz adresini, sonra yönetimin yanıt yolunu, sonra uygulamayı kontrol edin. Üçten ikisi yanlışsa seçenek işi taşımış ama ona bir sahip vermemiştir.

İlgili makaleler