PPP peer adresi mi VPN uç noktası mı: via'ya hangisi yazılır
Bir PPP arayüzünü alt ağ olarak okumakla inet ve peer değerlerini iki bağlantı ucu olarak okumayı karşılaştırın ve bir ilke tablosunun hangi sonraki atlamayı kabul edebileceğini görün.
PPP arayüzündeki tek bir satır, VPN kutusundaki yönlendirme tartışmasının büyük bölümünü çözer: iç adres ve yanında basılan peer. Bu çifti küçük bir alt ağ olarak okursanız var olmayan bir geçit arayacaksınız. Tek bir bağlantının iki ucu olarak okursanız sonraki atlama apaçık olur. Buradaki karşılaştırma bu iki okuma arasındadır, çünkü sonradan kurduğunuz her tablo seçtiğinizi devralır. Dış VPN uç noktası hakkında ikisi de hiçbir şey belirlemez.
Tek bir arayüz satırının iki okuması
inet 10.64.3.9 peer 10.64.3.1/32 bildiren bir oturum alın. Alt ağ okuması 10.64.3.9'u /32 adacığında yalnız bir ana bilgisayar sayar ve sonra ötesine ulaşmak için bir yönlendirici arar. Bağlantıdaki tek diğer adres peer olduğundan, bu okuma sonunda geçit olarak 10.64.3.9'un kendisini önerir, bu da döngüseldir.
Uç nokta okuması belgelenmiş olandır. Noktadan noktaya bir arayüzde peer bu tek bağlantının uzak ucunu adlandırır, bu yüzden 10.64.3.1 kullanılabilir sonraki atlamadır ve 10.64.3.9 her zaman yalnızca bir kaynak adresidir.
Bu fark via içinde neyin yer alabileceğini belirler. Oraya yerel adresi yazmak, çekirdeğin bir komşuya çözemeyeceği bir yol üretir, bu yüzden kayıt ya doğrulamada başarısız olur ya da bir listede tamamen sağlıklı görünürken trafiği yutar. Peer çalışır çünkü bağlantıdaki gerçek hedeftir. İki okuma da dış VPN uç noktası üzerinde anlaşır; bu tamamen ayrı bir kimliktir: ona underlay üzerinden ulaşılır, sonlandırdığı tünel üzerinden değil.
Oturumun zaten kurdukları
Kendi tablonuzu yazmadan önce bağlantıyla birlikte geleni yazdırın. Desteklenen bir PPP entegrasyonu genellikle oturum kurulumunda bir aygıt yolu ve bir peer yolu kurar ve bu iki kayıt doğru okumayı zaten kodlar.
ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5
10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 gibi bir aygıt yolu geçit taşımaz çünkü arayüzün kendisi yoldur. Peer'i via ile adlandıran bir yol, farklı ömrü olan başka bir nesnedir ve oturum düştüğünde kaybolur. İki biçimden birini yeniden nasıl kurulduğunu denetlemeden kalıcı bir tabloya kopyalamak, çalışan bir tünelin yeniden bağlanmadan sonra yolunu kaybetmesinin olağan nedenidir.
İki listeyi belleğe güvenmek yerine karşılaştırın. Peer yolu main içinde varsa ama ek tablonuz boşsa, adres satırının size hiç söylemediği bir şey öğrendiniz.
Kural ve tablo ayrı kararlardır
Bir tabloyu seçmek ve doldurmak bağımsız adımlardır ve karşılaştırma burada önemlidir çünkü hata ayıklarken ikisi sık sık karıştırılır. İşaretli trafiği tablo 100'e gönderen bir kural, tablo 100'de uygun bir yol yoksa hiçbir şey yapmaz, iyi doldurulmuş bir tablo ise ona hiçbir kural işaret etmiyorsa erişilemezdir.
Varsayılan yolun yarısı varsayılan yol değildir. Tek bir 0.0.0.0/1 IPv4 uzayının alt yarısını kapsar, bu yüzden her şeyi yakalamayı amaçlayan bir ilke eşleşen 128.0.0.0/1 ya da gerçek bir default da gerektirir. Çalışan bir yapılandırmayı okuyup iki yarıdan birini kopyalamak, insanların yalnızca belirli hedeflerde kırılan bir yönlendirme döngüsüne düşme biçimidir.
LAN'da kalması gereken adresler için bilinçli istisnalar bırakın ve arama seçilen tabloda hiçbir şey bulamadığında ne olacağına karar verin. Açık bir yedek yol, erişilemez bir sonuç döndüren ve uygulamayı yanlış yönlendirilmiş değil bozuk gösteren boş bir tablodan daha kolay düşünülür.
Aramaya uygulamanızın sorduğu soruyu sorun
ip route get bir yolu çözer; ip route show saklanan kayıtları listeler ve ikisi hiçbiri yanlış olmadan çelişebilir. Kaynak bağlamını ekleyin, çünkü kaynağa dayalı kurallar yalnızca arama bir kaynak taşıdığında eşleşir.
ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show
İlk komut soruyu ana bilgisayar tarafından sorar. İkincisi bir giriş arayüzü ekler, bu iletilen trafiğin yaşadığına daha yakındır ve yanıt çoğu zaman başka bir tabloya işaret eder. Hedeflerin hiçbiri canlı bir test hizmeti değildir; 198.51.100.23 bir belgeleme adresidir, bu yüzden onu yoklamanıza izin verilen bir ana bilgisayarla değiştirin.
Doğru bir arama bile yalnızca bir yolun seçildiğini kanıtlar. Karşı tarafın trafiği kabul edip etmediği ya da yanıtın aynı akıl yürütmeyle geri dönüp dönemeyeceği hakkında hiçbir şey söylemez.
Karşılaştırmanın ters döndüğü yer
Ana bilgisayar trafiği ve iletilen trafik yalnızca farklı aramalar yapmaz; dönüş yolunda farklı süzgeçlerle karşılaşır. Linux ters yol doğrulamasını tüm arayüzler ve alıcı arayüz ayarlarından daha katı olanı kullanarak uygular, bu yüzden bir arayüzün değerini değiştirmek görünür bir etki yaratmayabilir. İşarete dayalı yönlendirme, kaynağın geçerli sayılması için işaretin eşleşmesi gereken src_valid_mark ilişkisini ekler.
Giden yönlendirme doğru görünürken yanıtlar kaybolursa, onlara dokunmadan önce etkin değerleri okuyun ve yalnızca belirtilmiş bir ilke gerekçesiyle değiştirin.
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark
İki tasarım arasında kanıta dayanarak seçin: uygulama PPP adresine bağlanıyorsa bir kaynak kuralı ve peer yolunu tutan bir tablo yeterlidir. Kutu arkasındaki bir LAN için iletiyorsa giriş bağlamının ve dönüş yolunun da uyuşması gerekir. Uyuşmadıklarında, tüm makine için doğrulamayı gevşetmek yerine yolun sahipliğini düzeltin.