IPv4 adresleri tükendikçe birçok telekom operatörü, müşterilerine adres çevirisini kullanarak ağ erişimi sağlama ihtiyacıyla karşı karşıya kalıyor. Bu yazıda size emtia sunucularında Taşıyıcı Sınıfı NAT performansını nasıl alabileceğinizi anlatacağım.
Biraz tarih
IPv4 adres alanının tükenmesi konusu artık yeni değil. Bir noktada RIPE'de bekleme listeleri belirdi, ardından hangi adres bloklarının alınıp satıldığı borsalar ortaya çıktı ve bunları kiralamak için anlaşmalar yapıldı. Telekom operatörleri yavaş yavaş adres ve port çevirisini kullanarak İnternet erişim hizmetleri sağlamaya başladı. Bazıları, her aboneye “beyaz” bir adres vermek için yeterli adres almayı başaramadı, bazıları ise ikincil piyasadan adres satın almayı reddederek tasarruf etmeye başladı. Ağ ekipmanı üreticileri bu fikri destekledi çünkü bu işlevsellik genellikle ek genişletme modülleri veya lisanslar gerektirir. Örneğin, Juniper'ın MX yönlendirici serisinde (en son MX104 ve MX204 hariç), ayrı bir MS-MIC servis kartında NAPT gerçekleştirebilirsiniz, Cisco ASR1k bir CGN lisansı gerektirir, Cisco ASR9k ayrı bir A9K-ISM-100 modülü gerektirir ve kendisine A9K-CGN lisansı -LIC. Genel olarak zevk çok paraya mal olur.
IPTables
NAT gerçekleştirme görevi, özel bilgi işlem kaynakları gerektirmez, örneğin herhangi bir ev yönlendiricisine kurulan genel amaçlı işlemciler tarafından çözülebilir. Bir telekom operatörü ölçeğinde bu sorun, FreeBSD (ipfw/pf) veya GNU/Linux (iptables) çalıştıran ticari sunucular kullanılarak çözülebilir. FreeBSD'yi dikkate almayacağız çünkü... Bu işletim sistemini kullanmayı uzun zaman önce bıraktım, bu yüzden GNU/Linux'a sadık kalacağız.
Adres çevirisini etkinleştirmek hiç de zor değil. Öncelikle nat tablosundaki iptables'a bir kural kaydetmeniz gerekir:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent
İşletim sistemi, tüm aktif bağlantıları izleyecek ve gerekli dönüşümleri gerçekleştirecek nf_conntrack modülünü yükleyecektir. Burada birkaç incelik var. Öncelikle, bir telekom operatörü ölçeğinde NAT'tan bahsettiğimiz için zaman aşımlarını ayarlamak gerekir, çünkü varsayılan değerlerle çeviri tablosunun boyutu hızla felaket değerlerine ulaşacaktır. Aşağıda sunucularımda kullandığım ayarların bir örneği verilmiştir:
net.ipv4.ip_forward = 1
net.ipv4.ip_local_port_range = 8192 65535
net.netfilter.nf_conntrack_generic_timeout = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 45
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_checksum=0
İkincisi, çeviri tablosunun varsayılan boyutu bir telekom operatörünün koşullarında çalışacak şekilde tasarlanmadığından artırılması gerekir:
net.netfilter.nf_conntrack_max = 3145728
Tüm yayınları saklayan hash tablosu için kova sayısını artırmak da gereklidir (bu, nf_conntrack modülündeki bir seçenektir):
options nf_conntrack hashsize=1572864
Bu basit manipülasyonlardan sonra, çok sayıda müşteri adresini harici adreslerden oluşan bir havuza çevirebilen, tamamen çalışan bir tasarım elde edilir. Ancak bu çözümün performansı arzu edilenin çok ötesindedir. NAT için GNU/Linux kullanmaya yönelik ilk denemelerimde (yaklaşık 2013), sunucu başına 7Mpps hızında (Xeon E0.8-5v1650) yaklaşık 2Gbit/s performans elde edebildim. O zamandan beri GNU/Linux çekirdek ağ yığınında birçok farklı optimizasyon yapıldı, aynı donanımdaki bir sunucunun performansı 18-19 Mpps'de neredeyse 1.8-1.9 Gbit/s'ye yükseldi (bunlar maksimum değerlerdi) ancak tek bir sunucu tarafından işlenen trafik hacmine olan talep çok daha hızlı arttı. Sonuç olarak, farklı sunuculardaki yükü dengelemek için planlar geliştirildi, ancak tüm bunlar, sağlanan hizmetlerin kalitesinin ayarlanması, sürdürülmesi ve sürdürülmesinin karmaşıklığını artırdı.
NFTable'lar
Günümüzde, yazılım "vites değiştirme çantaları"nda moda olan bir trend, DPDK ve XDP'nin kullanılmasıdır. Bu konuyla ilgili pek çok makale yazıldı, pek çok farklı konuşma yapıldı ve ticari ürünler ortaya çıktı (örneğin VasExperts'in SKAT'ı). Ancak telekom operatörlerinin sınırlı programlama kaynakları göz önüne alındığında, bu çerçevelere dayalı herhangi bir "ürün"ü kendi başınıza oluşturmak oldukça sorunludur. Gelecekte böyle bir çözümü çalıştırmak çok daha zor olacak, özellikle teşhis araçlarının geliştirilmesi gerekecek. Örneğin, DPDK'lı standart tcpdump bu şekilde çalışmayacak ve XDP kullanılarak kablolara geri gönderilen paketleri "görmeyecektir". Paket iletiminin kullanıcı alanına gönderilmesine yönelik yeni teknolojiler hakkındaki tüm konuşmaların ortasında, bunlar fark edilmedi. и İptables sorumlusu Pablo Neira Ayuso, nftables'da akış boşaltmanın gelişimi hakkında. Bu mekanizmaya daha detaylı bakalım.
Ana fikir şudur: Eğer yönlendirici bir oturumdaki paketleri akışın her iki yönünde de aktardıysa (TCP oturumu KURULDU durumuna geçmişse), o zaman bu oturumun sonraki paketlerini tüm güvenlik duvarı kurallarından geçirmeye gerek yoktur, çünkü tüm bu kontroller, paketin yönlendirmenin daha da ilerisine aktarılmasıyla sona erecektir. Ve aslında bir rota seçmemize de gerek yok; bu oturumda hangi arayüze ve hangi ana bilgisayara paket göndermemiz gerektiğini zaten biliyoruz. Geriye kalan tek şey bu bilgiyi depolamak ve onu paket işlemenin erken bir aşamasında yönlendirme için kullanmaktır. NAT gerçekleştirirken, nf_conntrack modülü tarafından çevrilen adreslerdeki ve bağlantı noktalarındaki değişikliklerle ilgili bilgilerin ek olarak saklanması gerekir. Evet, elbette, bu durumda iptables'taki çeşitli polisler ve diğer bilgiler ve istatistiksel kurallar çalışmayı durdurur, ancak ayrı bir NAT veya örneğin bir sınır görevi çerçevesinde bu o kadar önemli değildir çünkü hizmetler cihazlara dağıtılır.
Yapılandırma
Bu işlevi kullanmak için ihtiyacımız var:
- Taze çekirdek kullanın. İşlevselliğin kendisi çekirdek 4.16'da ortaya çıkmasına rağmen, oldukça uzun bir süre çok "ham"dı ve düzenli olarak çekirdek paniğine neden oldu. LTS çekirdekleri 2019 ve 4.19.90'in piyasaya sürüldüğü Aralık 5.4.5 civarında her şey istikrara kavuştu.
- Nftables'ın oldukça yeni bir sürümünü kullanarak iptables kurallarını nftables biçiminde yeniden yazın. Tam olarak 0.9.0 sürümünde çalışır
İlk noktada prensipte her şey açıksa, asıl mesele modülü montaj sırasında konfigürasyona dahil etmeyi unutmamaktır (CONFIG_NFT_FLOW_OFFLOAD=m), o zaman ikinci noktanın açıklanması gerekir. nftables kuralları iptables'dakilerden tamamen farklı şekilde tanımlanır. neredeyse tüm noktaları ortaya koyuyor, ayrıca özel noktalar da var iptables'tan nftables'a kadar kurallar. Bu nedenle sadece NAT kurulumu ve akış boşaltma örneği vereceğim. Örneğin küçük bir efsane: , - bunlar trafiğin geçtiği ağ arayüzleridir; gerçekte ikiden fazlası olabilir. , — “beyaz” adresler aralığının başlangıç ve bitiş adresi.
NAT yapılandırması çok basittir:
#! /usr/sbin/nft -f
table nat {
chain postrouting {
type nat hook postrouting priority 100;
oif <o_if> snat to <pool_addr_start>-<pool_addr_end> persistent
}
}
Akış boşaltma ile durum biraz daha karmaşıktır ancak oldukça anlaşılırdır:
#! /usr/sbin/nft -f
table inet filter {
flowtable fastnat {
hook ingress priority 0
devices = { <i_if>, <o_if> }
}
chain forward {
type filter hook forward priority 0; policy accept;
ip protocol { tcp , udp } flow offload @fastnat;
}
}
Aslında tüm düzen budur. Artık tüm TCP/UDP trafiği fastnat tablosuna düşecek ve çok daha hızlı işlenecek.
Bulgular
Bunun ne kadar "çok daha hızlı" olduğunu açıklığa kavuşturmak için, aynı donanıma sahip (Xeon E5-1650v2), aynı şekilde yapılandırılmış, aynı Linux çekirdeğini kullanan, ancak iptables'da NAT gerçekleştiren iki gerçek sunucudaki yükün bir ekran görüntüsünü ekleyeceğim. (NAT4) ve nftable'larda (NAT5).
Ekran görüntüsünde saniye başına paket grafiği bulunmuyor ancak bu sunucuların yük profilinde ortalama paket boyutu 800 bayt civarında olduğundan değerler 1.5Mpps'ye kadar ulaşıyor. Gördüğünüz gibi nftables'ın bulunduğu sunucunun büyük bir performans rezervi var. Şu anda, bu sunucu 30Mpps'de 3Gbit/s'ye kadar işlem yapıyor ve boş CPU kaynaklarına sahipken 40Gbps'lik fiziksel ağ sınırlamasını açıkça karşılayabiliyor.
Bu materyalin, sunucularının performansını artırmaya çalışan ağ mühendisleri için yararlı olacağını umuyorum.
Kaynak: habr.com