Bir VPN rotası ip route çıktısında neden ağ geçidi göstermez
Cihazı olup ağ geçidi olmayan bir satır doğrudan rotadır, bozuk değil. Hedefi, dev ve scope alanlarını okuyun, ardından ip route get ile doğrulayın.
Yönlendirme tabloları, ağ geçidi sütunu boş kaldığında bozuk olarak okunur, oysa satır genellikle kendi başına tamdır. via alanı yalnızca çekirdek paketi bir sonraki atlama adresine teslim ettiğinde görünür; bir arayüze bağlı rota hedeflerine bunun yerine bağlantı katmanı çözümlemesi veya noktadan noktaya eş üzerinden ulaşır. Sütunları soldan sağa okumak hangi durumda olduğunuzu söyler ve bu okuma herhangi biri varsayılan rotayı düzenlemeden önce yapılmalıdır. Eksik ağ geçidiyle ilgili biletlerin çoğu bu ayrımda sona erer.
Rota satırını sütun sütun okuyun
Her giriş hedef ve önekinin uzunluğuyla başlar, ardından sabit bir sözlükte değiştiriciler ekler: via, dev, proto, scope, src ve metric. 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 gibi bir satır yoğundur ama tamamen belirtilmiştir. İçinde hiçbir şey eksik değildir ve herhangi bir yönlendirici adresi ima edilmez.
İlginç kısım via alanının yokluğudur. Sonraki atlama olmadan çekirdek hedefi doğrudan adlandırılan arayüzde çözer, bu bir tünel için çerçeveyi tünel aygıtına vermek ve kapsüllemenin oradan devam etmesine izin vermek anlamına gelir. proto kernel girişin bir adres atandığında otomatik olarak kurulduğunu kaydeder, bir yöneticinin yazdığını değil. scope link hedefe o bağlantı üzerinden yönlendiriciye uğramadan ulaşılabildiğini söyler ve src çekirdeğin eşleşen trafik için kaynak olarak tercih edeceği adresi adlandırır.
Şimdi varsayılan rotayı aynı şekilde okuyun: default via 192.0.2.254 dev eth0 proto static metric 100. Burada via vardır çünkü paketin gerçekten bir sonraki atlamaya ihtiyacı vardır ve bu atlamanın kendisi eth0 üzerinde ulaşılabilir olmalıdır. Bu iki satır birbirinin varyantı değildir; trafiğin nereye gittiğine dair farklı soruları yanıtlarlar.
Birbiriyle karıştırılan iki rota biçimi
Tünel alt ağı rotası ile varsayılan rota bir ekran görüntüsünde benzer görünür ve tamamen farklı davranır. Alanları okumak için aşağıdaki tabloyu yardımcı olarak kullanın, ardından bir kılavuzdaki örneğe güvenmek yerine hata ayıkladığınız makinede gerçek sayıları doğrulayın.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Tablonun söyleyemeyeceği şey niyettir. Bir tünel üzerinden özel bir aralığa doğrudan rota bilinçli bir bölünmüş tünel tasarımıdır; her şeyi VPN üzerinden göndermesi gereken bir ana bilgisayarda aynı biçimin görünmesi bir belirtidir. Niyet girişi üreten yapılandırmada yaşar, bu yüzden çekirdeğin bir şeyi yanlış yaptığı sonucuna varmadan önce onu kuran araca bakın.
Aynı şekilde eksik bir ağ geçidi bir tane uydurma izni değildir. Bir rota gerçekten bir sonraki atlamaya ihtiyaç duyuyorsa, o atlama onu taşıyan arayüzde ulaşılabilir olmalıdır, ve noktadan noktaya bir tünel için eş adresi yerel adresle aynı nesne değildir. Yerel tünel adresini bir Ethernet yönlendiricisi olarak ele almak, doğru görünen ve hiçbir şeyi iletmeyen bir rota üretmenin yaygın bir yoludur.
Çekirdeğe gerçekte hangi satırı kullanacağını sorun
Tabloyu okumak aramayı gerçekleştirmekle aynı değildir, çünkü çekirdek yanıtlamadan önce ilke kurallarına, birkaç tabloya ve önbelleğe alınmış girişlere başvurur. Gerçek aramayı gerçekleştiren fiil ip route get ve bu özelliklere sahip bir paketin izleyeceği rotayı yazdırır.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Gerçekten önemsediğiniz hedefi koyun, ardından trafik kaynağa göre seçildiğinde veya iletildiğinde from veya iif ekleyin, çünkü sıradan bir yerel arama iletilen bir istemciden farklı bir yol seçebilir. Yanıt arayüzü, seçilen kaynak adresini ve varsa sonraki atlamayı adlandırır, bu da paketin o anda yönlendirileceği bilginin aynısıdır.
Yanıt sizi şaşırtırsa, herhangi bir şeyi değiştirmeden önce kuralları yazdırın: ip -4 rule show onları öncelik sırasına göre listeler ve kendi tablosunu veya işaretli paketler için bir kural kuran bir VPN istemcisi ana tabloda hiç görünmez. Her tabloyu listelemek bu boşluğu kapatır.
ip -4 route show table all | grep -E 'tun|default'Varsayılanı değiştirmeden önce alt katmanı denetleyin
Tünelin kendi paketleri uzak uç noktaya ulaşmalıdır ve bunu VPN devreye girmeden önce var olan rotayı kullanarak fiziksel arayüz üzerinden yaparlar. Tüm varsayılan rotayı o uç noktayı sabitlemeden değiştirmek, kapsüllenmiş paketleri kurmaları gereken tünele gönderir ve bağlantı çöker. Önce yalnızca uç noktanın adresi için bir aramayla uç nokta yolunu doğrulayın.
Değişikliği yaparken üç şeyi ayrı tutun: fiziksel arayüzde kalması gereken uç nokta rotası, tünele girmesi gereken özel aralıklar ve geri kalan her şeye karar veren varsayılan. Bunları bu sırayla ayırın, tek tek uygulayın ve her adımdan sonra aramayı yeniden çalıştırın. Sonradan başarısız bir ping kendi başına çok az şey kanıtlar, çünkü izinler, yanıt yönlendirmesi, DNS ve hizmetin kendisi doğru bir rotanın akış aşağısında durur.
Düzenlemeden önce satırın size verdiği dört değeri yazın: hedef, sonraki atlama veya yokluğu, aygıt ve seçilen kaynak. Daha sonraki bir değişiklik bunlardan herhangi birini kaydırırsa hangi kararın gerçekten değiştiğini bilirsiniz ve tüm tabloyu tahmin etmek yerine tek bir girişi geri yükleyebilirsiniz.