3.6 sonrası çekirdeklerde çok yollu yönlendirme


16

Hepinizin bildiği gibi, ipv4 yol önbelleği, çok yollu yönlendirme üzerinde ciddi etkisi olan 3.6 Linux çekirdek serisinde kaldırılmıştır. IPv4 yönlendirme kodu (IPv6'dan farklı olarak) bir sonraki sekmeyi yuvarlak devir şeklinde seçer, bu nedenle verilen kaynak IP'den verilen hedef IP'ye kadar olan paketler her zaman aynı sonraki atlamadan geçmez. 3.6'dan önce yönlendirme önbelleği, bir sonraki seçildiğinde bir kez seçildiği gibi önbellekte kaldığı için durumu düzeltiyordu ve aynı kaynaktan aynı hedefe giden diğer tüm paketler bir sonraki sekmeden geçiyordu. Şimdi sonraki hop her paket için yeniden seçildi, bu da garip şeylere yol açıyor: yönlendirme tablosunda 2 eşit maliyetli varsayılan yolla, her biri bir internet sağlayıcısına işaret ediyor, TCP bağlantısı bile kuramıyorum, çünkü ilk SYN ve son ACK farklı yollardan geçebilir,

Çok yollu yönlendirme normal davranışını geri yüklemek için nispeten kolay bir yol var mı, böylece paket başına değil de akış başına bir sonraki atlama seçilir mi? IPv4'ün sonraki hop seçimini karma tabanlı hale getirmek için IPv6 için olduğu gibi yamalar var mı? Ya da bununla nasıl başa çıkıyorsunuz?


Şuna benzer bir "bölünmüş erişim" kurulumunuz var: lartc.org/howto/lartc.rpdb.multiple-links.html ? Öyleyse, kural kümeniz ve rotalarınız nasıl görünüyor?
the-wabbit

"ip yolu almak 173.194.112.247" birden çok kez kullanmaya çalışın ve çıktı sonrası
c4f4t0r

Lezzetli soru için teşekkürler. :) her şeyden önce bize bir örnek vermediniz. Sanırım ip ro add 8.8.8.8/32 nexthop via 1.2.3.4 nexthop via 1.2.3.5bu doğru varsayım gibi bir şeye sahip misiniz ?
poige

Evet, bu doğru, ama genellikle ip yolu sonraki birden fazla atlama ile 0.0.0.0/0 ekleyin.
Eugene

wabbit, evet, aynen böyle. Benim durumumda "sağlayıcı 1" ve "sağlayıcı2", iç ağım ve sağlayıcının ağına bağlı sınır yönlendiricilerdir ve NAT kaynağıdır. Dahili yönlendiricimde, sağlayıcı1 ve sağlayıcı2'yi işaret eden 2 şeridi olan varsayılan ağ geçidim var, başka rota yok. Güvenlik duvarı kuralları, istemci makineler için bazı hizmetlere (HTTP gibi) izin verir ve diğer her şeyi engeller.
Eugene

Yanıtlar:


8

Mümkünse Linux Çekirdeği> = 4.4 .... 'e yükseltin.

Birçok yönden 3.6 öncesi davranıştan daha iyi olan karma tabanlı çok yollu yönlendirme getirilmiştir. Akış tabanlıdır, yolu ayrı bağlantılar için sabit tutmak için kaynak ve hedef IP'lerin bir karma değerini (bağlantı noktaları yoksayılır) alır. Bir dezavantajı, 3.6 öncesi kullanılabilir çeşitli algoritmalar / yapılandırma modları olduğuna inanıyorum, ama şimdi size verilen ne olsun !. weightYine de yol seçimini etkilemek için kullanabilirsiniz .

Eğer benim durumumda iseniz o zaman aslında istiyorsun 3.6 >= behaviour < 4.4ama artık desteklenmiyor.

> = 4.4 sürümüne yükseltirseniz, bu işlem diğer tüm komutlar olmadan da yapılmalıdır:

ip route add default  proto static scope global \
nexthop  via <gw_1> weight 1 \
nexthop  via <gw_2> weight 1

Alternatif olarak cihaza göre:

ip route add default  proto static scope global \
 nexthop  dev <if_1> weight 1 \
 nexthop  dev <if_2> weight 1

Bu çözüme gelen herkes için - ayrıca göz atın: net.ipv4.fib_multipath_use_neigh "düştü" nexthop / ağ geçidini otomatik olarak devre dışı bırakmak için.
Rostislav Kandilarov

6

"Nispeten kolay" zor bir terimdir, ancak

  1. her bağlantınız için yönlendirme tabloları ayarlama - tek bir varsayılan ağ geçidi ile bağlantı başına bir tablo
  2. tek bir akışın tüm paketlerine aynı işaretleri damgalamak için netfilter kullanın
  3. İşaretlere bağlı olarak paketleri farklı yönlendirme tabloları üzerinden yönlendirmek için ip kural tablosunu kullanın
  4. oturumdaki ilk paketleri ağ geçitleriniz / bağlantılarınız arasında dengelemek için çok aşamalı ağırlıklı bir rota kullanın.

Bir olmamıştır netfilter posta listesinin en tartışma ben den listeleri çalıyorum bu konuda:

1. Yönlendirme kuralları (RPDB ve FIB)

ip route add default via <gw_1> lable link1
ip route add <net_gw1> dev <dev_gw1> table link1
ip route add default via <gw_2> table link2
ip route add <net_gw2> dev <dev_gw2> table link2

/sbin/ip route add default  proto static scope global table lb \
 nexthop  via <gw_1> weight 1 \
 nexthop  via <gw_2> weight 1

ip rule add prio 10 table main
ip rule add prio 20 from <net_gw1> table link1
ip rule add prio 21 from <net_gw2> table link2
ip rule add prio 50 fwmark 0x301 table link1
ip rule add prio 51 fwmark 0x302 table link2
ip rule add prio 100 table lb

ip route del default

2. Güvenlik duvarı kuralları ("flow" LB modunu zorlamak için ipset kullanarak)

ipset create lb_link1 hash:ip,port,ip timeout 1200
ipset create lb_link2 hash:ip,port,ip timeout 1200

# Set firewall marks and ipset hash
iptables -t mangle -N SETMARK
iptables -t mangle -A SETMARK -o <if_gw1> -j MARK --set-mark 0x301
iptables -t mangle -A SETMARK -m mark --mark 0x301 -m set !
--match-set lb_link1 src,dstport,dst -j SET \
          --add-set lb_link1 src,dstport,dst
iptables -t mangle -A SETMARK -o <if_gw2> -j MARK --set-mark 0x302
iptables -t mangle -A SETMARK -m mark --mark 0x302 -m set !
--match-set lb_link2 src,dstport,dst -j SET \
          --add-set lb_link2 src,dstport,dst

# Reload marks by ipset hash
iptables -t mangle -N GETMARK
iptables -t mangle -A GETMARK -m mark --mark 0x0 -m set --match-set
lb_link1 src,dstport,dst -j MARK --set-mark 0x301
iptables -t mangle -A GETMARK -m mark --mark 0x0 -m set --match-set
lb_link2 src,dstport,dst -j MARK --set-mark 0x302

# Defining and save firewall marks
iptables -t mangle -N CNTRACK
iptables -t mangle -A CNTRACK -o <if_gw1> -m mark --mark 0x0 -j SETMARK
iptables -t mangle -A CNTRACK -o <if_gw2> -m mark --mark 0x0 -j SETMARK
iptables -t mangle -A CNTRACK -m mark ! --mark 0x0 -j CONNMARK --save-mark
iptables -t mangle -A POSTROUTING -j CNTRACK

# Reload all firewall marks
# Use OUTPUT chain for local access (Squid proxy, for example)
iptables -t mangle -A OUTPUT -m mark --mark 0x0 -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -m mark --mark 0x0 -j GETMARK
iptables -t mangle -A PREROUTING -m mark --mark 0x0 -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark --mark 0x0 -j GETMARK

Yukarıdakilerin bazı varyasyonları için netfilter posta listesi tartışmasını takip etmek isteyebilirsiniz.


Emin değilim, ama u32önemli parametreler elde etmek daha basit olabilir ve daha sonra ip rule's
poige

Teşekkür ederim, ama bu oldukça karmaşık bir çözüm gibi görünüyor. Tam olarak anlamadığım şey, buradaki hangi parçanın "tek bir akışın tüm paketlerine aynı işaretleri damgalamaktan" sorumlu olduğudur? Bu ipset sihri nasıl çalışır? Ben ipset sadece hashed ve kurallar halinde eşleştirilebilir belirli IPs bir dizi olduğunu düşündüm.
Eugene

Haklısın ipset- sadece doldurulmuş --add-setve kullanıma karşı eşleşen setler oluşturuyor --match-set- ama bu çoğunlukla YENİ durumdaki bağlantılar içindir. KURULAN durum bağlantıları için işaret, hedef --restore-markparametresi kullanılarak paketlerin üzerine damgalanır CONNMARK- bu yönerge bağlantının işaretini pakete kopyalar. Bağlantının işareti daha önce kullanılarak ayarlanır --save-markiçinde POSTROUTING(YENİ bağlantıları ait paketlerin içinden geçecek yerde) zinciri. Senaryo benim için aşırı derecede kıvrımlı görünüyor, ama fikri iletiyor.
the-wabbit

1
Evet, şimdi bir fikrim var, sanırım. Son soru: çekirdek geliştiricileri neden ipv4 için karma tabanlı bir sonraki hop seçimi sunmuyorlar? Güzergah önbelleğinin kaldırılmasıyla birlikte uygulanmamasının bir nedeni var mı? İpv6 için benzer çözüm oldukça iyi çalışıyor. Bütün bu sihir, bu kadar basit bir görev için aşırıya kaçmıyor mu?
Eugene

1
@Ne yazık ki, ne yazık ki, sorularınızı herhangi birisine yetkili olarak cevaplamak için IP yığını geliştirmesine (veya genel olarak Linux Çekirdeği geliştirmesine) yeterince yakın olmaktan çok uzaktayım, ancak IPv4 ile farklı sağlayıcılar kullanarak çoklu yolun çok fazla olarak kabul edildiğini tahmin ediyorum. içine daha fazla iş koymak için bir köşe durumda. Netfilter CONNMARK'lerin kullanılması açık bir şekilde kötü bir çamur gibi gözükse de, rota önbellek kodunu düşürme kararında "kullanılabilir bir geçici çözüm" olarak düşünülmüş olabilir.
wabbit
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.