LAN sunucusunda VPN istemcisi: yanıtlar neden yanlış yoldan çıkıyor

Belirtiler tek bir şekli izler: bir ana makine çalışır, sonra istemci olarak bir VPN'e bağlanır ve artık LAN istemcileri ona ulaşırken yanıtları kaybolur. Ana makinedeki yakalama, yanıtların LAN arayüzü yerine tünel aygıtından çıktığını gösterir. Tünelde bozuk bir şey yoktur ve düzeltme bir rotadır, yeniden bağlanma değil. Aşağıdaki dört denetimi sırayla yapın ve ilk başarısız olanda durun.

Yanıt yeni bir pakettir, yolun tersine dönüşü değil

Yanıtın bir isteğin gittiği yoldan geri döndüğü fikrini bırakmak yardımcı olur. Yönlendirme her paket ve her yön için gönderen ana makinede kararlaştırılır. Tünelin içinde 10.64.0.23 adresinden gelen istek bir dönüş yolu oluşturmaz; ana makine yanıtladığında o yanıt yeni bir paket olarak tabloyla karşılaştırılır ve kazanan rotadan çıkar.

Bu yüzden LAN'a da hizmet veren bir makinede tam tünel istemcisi bu kadar kafa karıştırıcı bir arıza üretir. İstemci varsayılan bir rota veya bazı istemcilerin tercih ettiği iki yarım varsayılan rota kurar ve LAN istemcisine giden yanıt artık tünele uyar. Sağlayıcıya gider, onun iletmesi için bir neden yoktur ve ana makine çalışıp yerelde yanıt vermesine rağmen LAN istemcisi zaman aşımı görür. Yakalama bunu apaçık gösterir ve yönlendirme tablosu açıklar.

Kalanı okurken iki alt ağı aklınızda tutun. Biri uzak istemcilerin geldiği VPN adres havuzudur, bu örnekte 10.64.0.0/24. Diğeri çalışmaya devam etmesi gereken LAN'dır, 172.16.24.0/24 ve yönlendiricisi 172.16.24.1 üzerindedir. Hata, aralarındaki trafiğin varsayılan rota tarafından belirlenmesidir.

Yakalama ve sorguyla kanıtlayın

Herhangi bir şeyi değiştirmeden önce yanıtın hangi aygıtı kullanacağını doğrulayın. Sorgu yakalamadan hızlıdır ve paket oluşturulurken çekirdeğin yanıtlayacağı sorunun aynısını yanıtlar.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Yanıtı iki bölümde okuyun. dev tun0 diyorsa ana makine yanıtı kapsülleyip sağlayıcıya verir ve LAN istemcisi onu asla görmez. dev eth0 diyor ama istemci yine zaman aşımına uğruyorsa rota zaten doğrudur ve paket daha sonra atılır; bu başka bir sorun ve başka bir düzeltmedir.

Aynı adımdaki yakalama, ping'in çözemeyeceği kuşkuyu giderir. LAN istemcisine ulaşan bir yankı yanıtı bir yolun çalıştığını kanıtlar, hangi arayüzün taşıdığını değil, bu yüzden yakalamayı ana makinenin kendisinde yapın ve çerçevelerin nereden çıktığına bakın. Aynı alt ağdaki yazıcı yanıt vermeye devam eder, çünkü doğrudan rotası tünelin varsayılanından daha belirlidir. Yönlendirilmiş bir bağlantı noktası diğer her akış gibi başarısız olur, çünkü arayüzü tablo seçer, bağlantı değil.

Tüneli aşan en dar rotayı kurun

Önek uzunluğu belirler, metrik değil, bu yüzden istemci havuzu için LAN yönlendiricisi üzerinden bir rota, VPN istemcisinin kurduğu her varsayılan rotayı yener. Metrik cerrahisi gerekmez ve varsayılan rota istemcinin koyduğu yerde kalabilir.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

add yerine replace kullanın, çünkü yeniden bağlanan istemci kendi girdisini kurmuş olacaktır ve ikinci add, izin sorunu gibi okunan varolan rota hatasıyla başarısız olur. Bir Windows ana makinesinde eşdeğeri route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p olur; burada -p, tünel yeniden kalktığında istemci tabloyu yeniden kurabildiği için girdiyi yeniden başlatmalar arasında korur. Güncel bir Windows ana makinesinde desteklenen eşdeğer New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore olur ve eski route komutu eski biçim olarak korunur.

Bir ayrıntı bunun doğru mu yoksa yalnızca akla yatkın mı olduğunu belirler: sonraki atlama, istemcilere dönüş yolunu gerçekten elinde tutan yönlendirici olmalıdır. Rotayı kendisi tünelden ulaşılan bir adrese yöneltmek, temiz bir arıza yerine aralıklı kayıp olarak görünen bir döngü yaratır. Satırı onaylamadan önce sonraki atlamanın LAN alt ağında olduğunu doğrulayın.

Yeniden bağlanmadan sonra yanıtı koruyun

Elle eklenen bir rota en iyi durumda bir sonraki yeniden bağlanmaya kadar yaşar. İstemci havuzu dinamikse, yönlendirdiğiniz önekin istemcilerin aldığı önek olarak kalması için sunucu yapılandırmasına sabitleyin; aksi halde girdi boş bir aralığa işaret eder ve belirti haftalar sonra belirgin bir neden olmadan geri döner. Rotayı istemcinin kendi up betiğine yazmak diğer güvenilir seçenektir, çünkü istemci tabloyu yeniden yazdıktan sonra çalışır.

Durum bilgili bir güvenlik duvarı doğru bir rotayı yine de yenebilir. Yakalama artık yanıtın eth0 üzerinden çıktığını gösteriyor ama istemci yine zaman aşımına uğruyorsa, ana makinenin paketi göndermeden önce atıp atmadığını kontrol edin. Katı ters yol filtrelemesi ve net.ipv4.conf.all.rp_filter değerinin 1 olması, kaynağı geldiği arayüzden geri yönlendirilmeyecek paketleri atar ve bu tam olarak az önce oluşturup sonra düzelttiğiniz asimetrik durumdur; conntrack durumu da yönlendirilmiş bağlantı noktaları için aynı hikâyeyi anlatır.

Son denetim insanların atladığı denetimdir: tünel kapandıktan ve yeniden açıldıktan sonra sorguyu yineleyin. Dört değer yazdıklarınızla eşleşmelidir: hedef, sonraki atlama, aygıt ve seçilen kaynak. Bunlardan biri yer değiştirdiyse istemci tabloyu yeniden yazmıştır ve düzeltme onun kancalarına aittir, bir shell geçmişine değil.