Bölünmüş tünel yolları çakıştığında: hangi önek kazanır

İki bölünmüş tünel profili, iki özel önek ve ikisinin de sahiplendiği bir ana bilgisayar. Belirti nadiren temiz bir arızadır: bir hizmet Pazartesi günü çalışır, ikinci istemci yeniden bağlandıktan sonra zaman aşımına uğrar ve yeniden başlatmadan sonra tekrar çalışır. İstemcileri bağlama sıranız sonucu belirlemez, istemcinin arayüzündeki satır sırası da belirlemez. Bu denetimleri sırayla yapın ve tutmayan ilk denetimde durun, çünkü sonrakiler ancak öncekiler doğruysa anlam taşır.

1. Hedefi ve kaynağı yazın

Başarısız isteğin gittiği tam adresten başlayın, ana bilgisayar adından değil ve uygulama adından değil. Adı bir kez çözün, her yanıtı not edin ve başarısız akışın gerçekten kullandığını seçin. Ardından aynı akışın yerel adresini not edin, çünkü kaynak adresi hangi politika kuralının eşleştiğini ve dolayısıyla hangi tabloya bakıldığını değiştirebilir.

Birkaç A kaydından birine giden istek başarısız olurken kardeş adres başarılı olabilir, bu istikrarsız bir tünel gibi görünür ama aslında iki farklı yoldur. Hedef birkaç yanıtı olan bir adsa, herhangi bir şeyi değiştirmeden önce her yanıtı ayrı ayrı deneyin.

2. Çekirdeğe hangi yolu seçtiğini sorun

Yönlendirme tablosunu okuyup yanıtı çıkarsamayın. Yığının sorduğu sorunun aynısını aynı kaynak adresle sorun: Linux'ta ip route get 10.20.4.10 from 10.8.0.2 veya PowerShell'de Find-NetRoute -RemoteIPAddress 10.20.4.10. Çıktı gerçekte kullanılacak yolu adlandırır ve bu genellikle tabloyu okurken beklediğiniz yol değildir.

Eşleşen yollar arasında genellikle daha belirgin önek kazanır: ikisinin içinde olan bir adres için /24, /16'yı yener. Aynı uzunluktaki eşleşmeler arasında daha düşük metrik kazanır ve kapalı bir bağlantı üzerine kurulmuş yol atlanır. Aynı /24'ü aynı metrikle iten iki tünel başka bir durumdur: çekirdek iki yolu da tutar ve aralarında seçim yapar, böylece sonuç istemcilerin bağlanma sırasını izlemek yerine değişebilir. Pazartesi-çalışır-Salı-başarısız olur kalıbını üreten tam olarak bu durumdur ve başka bir sırayla yeniden bağlanmak bunu değiştirmez.

3. Bir politika kuralının aramayı başka yöne çevirip çevirmediğini kontrol edin

Yönlendirme tablosuna bakılmadan önce çekirdek kendi politika kurallarını dolaşır. Bir kural, belirli bir kaynaktan, kullanıcıdan veya güvenlik duvarı işaretinden gelen trafiği tamamen başka bir tabloya gönderebilir, bu yüzden ana tablodaki kazanan önek o akış için hiçbir zaman görülmeyebilir. ip rule show bunları değerlendirme sırasına göre listeler ve ip route show table 100 seçilen tablonun gerçekte ne içerdiğini gösterir.

Burada iki tuzak var. Boş bir tabloyu işaret eden kural, bir sonraki kurala düşen bir arama üretir, bu yüzden kural hiçbir şey yapmıyormuş gibi görünür. Diğeri öncelik numarasının kendisidir: kurallar artan sırayla okunur ve yerleşik değerler 0 local, 32766 main ve 32767 default'tur. Numarası 32767'nin altında olan kural, her şeyi yakalayan varsayılan kuraldan önce bakılır. Numarası 32767'nin üzerinde olan kural onun arkasında durur ve yalnızca hiçbir önceki tablo yanıt vermediğinde ulaşılır; main içindeki normal varsayılan yönlendirme bunu engeller, bu yüzden pratikte ona hiçbir zaman ulaşılmaz ve kurulu görünürken sessizce hiçbir şey yapmaz. İstemci bir kural ve bir yol yazdıysa ikisini de kontrol edin ve yeniden bağlandıktan sonra tekrar kontrol edin, çünkü yeniden yazılmış bir profil farklı öncelikte ikinci bir kural ekleyebilir.

4. Yönlendirme beraberliğini çoğaltılmış adres planından ayırın

Bazen önek hiç sorun değildir. İki sitenin de 192.168.1.0/24 kullanması, aynı adresin iki farklı ana bilgisayarı tanımladığı anlamına gelir ve hiçbir yol onları ayırt edemez. İki yanıttan birine giden ana bilgisayar yolu, diğer site aynı ad için yanıt verene kadar çalışır ve sonra istisna sessizce hatanın kendisi olur.

İşaret, hedef adresin iki yolda da aynı olması ve yalnızca amaçlanan sahibin farklı olmasıdır. Bu bir adres planı kararıdır, yönlendirme ayarı değil: bir tarafı yeniden numaralandırın, bir tarafı çeviri yapan bir geçidin arkasına koyun veya ikinci siteye kendi adlarını çözen bir vekil sunucu üzerinden ulaşın. Varsayılan yolu düşürmek veya ana bilgisayar istisnalarını yığmak yalnızca çakışmayı taşır.

5. Çözümleyicinin yolla aynı fikirde olduğunu doğrulayın

Yanlış özel adrese çözülen bir ad, bir yönlendirme çakışmasının tüm belirtilerini üretir ve nedenlerinden hiçbirini üretmez. Ana bilgisayarın aldığı yanıtı hedefin gerçekte kullandığı adresle karşılaştırın ve hangi çözümleyicinin yanıt verdiğini kontrol edin. Tünel bir çözümleyici itiyorsa istemci bunu tüneli kullanan akışlar için kurmalıdır; itmiyorsa ana bilgisayar yerel çözümleyiciye sormaya devam eder, o da arama etki alanından veya önbelleğe alınmış bir kayıttan yanıt verebilir.

Çözümleyiciye doğrudan sorun ve yanıt veren sunucuyu not edin. Kısa TTL'li önbelleğe alınmış bir yanıt, yeniden bağlandıktan sonraki ilk isteğin beşinciden neden farklı davrandığını da açıklayabilir.

6. Yeniden bağlanın, uygulanan durumu inceleyin ve sonra iki akışı da test edin

Bir düzeltmeden sonra yeniden bağlanın ve profil düzenleyicisine güvenmek yerine istemcinin gerçekte ne kurduğunu inceleyin. Kuralları, tabloları ve ortaya çıkan ip route get yanıtını tekrar okuyun. İkinci bir istemci bağlanırken kendi yolunu yeniden kurabilir ve çakışmayı yeniden yaratabilir, bu yüzden durum kontrolü son istemci bağlandıktan sonra yapılmalıdır, önce değil.

Bir değil iki akışı test edin: eskiden başarısız olan isteği ve diğer tüneli kullanması gereken kaynağı. Tüm özel trafiği tek bir bağlantıya taşımak ilk testi geçirirken ikincisini bozar ve bunu yalnızca eşleştirilmiş bir test yakalar. Sakladığınız her istisnayı hedef ve gerekçeyle birlikte kaydedin, böylece sonraki kişi kasıtlı bir ana bilgisayar yolunu kalandan ayırabilsin.