Висок трафик и прекъсвания на Linux, рутер и NAT сървър
В нашата градска мрежа има повече от 30 хиляди абонати. Общият обем на външните канали е повече от 3 гигабита. И съветите, дадени в споменатата статия, преминахме през преди няколко години. Затова искам да разширя темата и да споделя с читателите моите най-добри практики в рамките на повдигнатия проблем.
Бележката описва нюансите на конфигуриране / настройка на рутер и NAT сървър под Linux, както и някои пояснения относно разпределението на прекъсванията.
Прекъсва
Разпръскването на прекъсвания на мрежовата карта в различни ядра е първото нещо, с което се сблъсква системният администратор, когато натоварването на linux рутера се увеличи. В споменатата статия темата е разгледана достатъчно подробно - затова няма да се спираме дълго на този въпрос.
Искам само да отбележа:
- ако ръчно хвърляте прекъсвания, тогава трябва да спрете услугата irqbalance. Тази услуга е предназначена само за автоматично регулиране на прекъсванията между процесорните ядра. Ако извършвате тази работа ръчно, по-добре е да спрете услугата;
- не забравяйте да направите съответните промени в "autoload" (например /etc/rc.local) - защото след рестартиране на сървъра, всички прекъсвания отново ще бъдат разпределени в куп на едно ядро;
- след рестартиране на сървъра, мрежовите карти могат да получат (и най-вероятно това ще бъде така) нови номера на прекъсване. Следователно в /etc/rc.local е по-добре да не въвеждате конкретни номера на прекъсвания на ръка - а да автоматизирате, използвайки спомагателен скрипт, разпознаването на кое мрежово прекъсване кое е взело.
рутер
В оригиналната статия има фраза „ако сървърът работи само като рутер, тогава настройката на TCP стека на специаленняма значение." Това твърдение е фундаментално погрешно. Разбира се, настройката не играе голяма роля при малки потоци. Ако обаче имате голяма мрежа и съответното натоварване, тогава ще трябва да се справите с настройката на мрежовия стек.
На първо място, ако гигабитите „ходят“ във вашата мрежа, тогава има смисъл да обърнете внимание на MTU на вашите сървъри и комутатори. Накратко, MTU е количеството пакет, което може да бъде предадено по мрежата, без да се прибягва до фрагментирането му. Тези. колко информация вашият един рутер може да предаде на друг без фрагментиране. При значително увеличаване на количеството данни, предавани по мрежата, е много по-ефективно да изпращате по-големи пакети по-рядко, отколкото да изпращате малки пакети данни често, често.
Увеличаване на MTU на linux
/sbin/ifconfig eth0 mtu 9000
Увеличаване на MTU на комутаторите
При превключващо оборудване това обикновено се нарича джъмбо рамка. По-специално за Cisco Catalyst 3750
3750(config)# система mtu jumbo 9000 3750(config)# изход 3750# презареждане
Обърнете внимание, че след това комутаторът трябва да се рестартира. Между другото, mtu jumbo се отнася само за гигабитови връзки - такава команда не засяга 100-Mbps.
Увеличаване на опашката за предаване на linux
/sbin/ifconfig eth0 txqueuelen 10000
Стойността по подразбиране е 1000. За гигабитови връзки се препоръчва да зададете 10000. Накратко, това е размерът на буфера за предаване. Когато буферът се запълни до този лимит, данните се прехвърлят към мрежата.
Имайте предвид, че ако промените размера на MTU на интерфейса на някакъв хардуер, трябва да направите същото и на интерфейса на неговия „съсед“. Тоест, ако сте увеличили MTU до 9000 на интерфейса на linux рутера, тогава трябва да активирате jumbo-frame на порта на комутатора, към който този рутервключени. В противен случай мрежата ще работи, но много зле: пакетите ще преминат през мрежата "през един".
В резултат на всички тези промени „пинговете“ ще се увеличат в мрежата - но общата пропускателна способност ще се увеличи значително и натоварването на активното оборудване ще намалее.
NAT сървър
Операцията NAT (Network Address Translation) е една от най-скъпите (в смисъл ресурсоемки). Следователно, ако имате голяма мрежа, не можете да направите без настройка на NAT сървъра.
Увеличете броя на наблюдаваните връзки
За да изпълни задачата си, NAT сървърът трябва да "запомни" всички връзки, които преминават през него. Независимо дали става въпрос за "ping" или за нечии "ICQ" - всички тези сесии NAT сървърът "помни" и ги следи в паметта си в специална таблица. Когато една сесия е затворена, информацията за нея се премахва от таблицата. Размерът на тази таблица е фиксиран. Ето защо, ако има много трафик през сървъра и няма достатъчно размер на таблицата, тогава NAT сървърът започва да „пуска“ пакети, прекъсва сесии, интернет започва да работи с ужасни прекъсвания и понякога дори става невъзможно да се стигне до самия NAT сървър чрез SSH.
За да предотвратите подобни ужаси, е необходимо да увеличите адекватно размера на таблицата - в съответствие с трафика, преминаващ през NAT:
/sbin/sysctl -w net.netfilter.nf_conntrack_max=524288
Силно НЕ се препоръчва да задавате толкова голяма стойност, ако имате по-малко от 1 гигабайт RAM на NAT сървъра.
Можете да видите текущата стойност по следния начин:
За да видите колко пълна вече е таблицата за проследяване на връзката, можете да направите следното:
Увеличаване на размера на хеш таблицата
Хеш-таблицата, която съхранява списъци с conntrack записи, също трябва да бъде увеличена пропорционално.
ехо65536 > /sys/module/nf_conntrack/parameters/hashsize
Правилото е просто: hashsize = nf_conntrack_max / 8
Намаляване на стойностите на изчакване
Както си спомняте, NAT сървърът следи само "живите" сесии, които преминават през него. Когато сесията е затворена, информацията за нея се изтрива, за да не се препълни таблицата. Информацията за сесиите също се изтрива при таймаут. Тоест, ако няма трафик в рамките на обменната връзка за дълго време, тя се затваря и информацията за нея също се изтрива от NAT паметта.
Стойностите за изчакване по подразбиране обаче са доста големи. Следователно, при големи потоци на трафик, дори ако разтегнете nf_conntrack_max до краен предел, пак рискувате бързо да попаднете в препълване на таблицата и прекъсвания на връзката.
За да предотвратите това да се случи, трябва да зададете правилно времето за изчакване за проследяване на връзката на NAT сървъра.
Текущите стойности могат да се видят например така:
sysctl -a grep conntrack grep таймаут
В резултат на това ще видите нещо подобно:
net.netfilter.nf_conntrack_generic_timeout = 600 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60 net.netfilter.nf_conntrack_tcp_timeout_establi shed = 4320 00 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30 net.netfilter.n f_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_ таймаут = 30 net.netfilter.nf_conntrack_udp_timeout_stream = 180 net.netfilter.nf_conntrack_icmp_timeout = 30 net.netfilter.nf_conntrack_events_retry_timeout = 15
Това са стойностите на времето за изчакване в секунди. Както можете да видите, стойността на net.netfilter.nf_conntrack_generic_timeout е 600 (10 минути). Тези. NAT сървърът ще пази в паметта информация за сесията, докато "работи" поне нещо поне веднъж на всеки 10 минути.
На пръв поглед нищо ужасно - но всъщност е много, много.
Ако погледнете net.netfilter.nf_conntrack_tcp_timeout_established, там ще видите стойността 432000. С други думи, вашият NAT сървър ще проследи обикновена TCP сесия, докато някой пакет премине през нея поне веднъж на всеки 5 дни (!).
С още по-прости думи става лесно да се DDOS такъв NAT сървър: неговата NAT таблица (параметърът nf_conntrack_max) се препълва "с гръм и трясък" с най-простото наводнение - в резултат на това ще прекъсне връзките и в най-лошия случай бързо ще се превърне в черна дупка.
Стойностите за изчакване се препоръчват да бъдат зададени в рамките на 30-120 секунди. Това е напълно достатъчно за нормалната работа на абонатите и това е напълно достатъчно за навременното почистване на NAT таблицата, което изключва нейното препълване.
И не забравяйте да напишете съответните промени в /etc/rc.local и /etc/sysctl.conf
След настройка ще получите напълно жизнеспособен и продуктивен NAT сървър. Разбира се, това е само "основна" настройка - не сме докосвали, например, настройка на ядрото и т.н. от нещата. В повечето случаи обаче дори такива прости действия ще бъдат достатъчни за нормалната работа на доста голяма мрежа. Както вече казах, в нашата мрежа има повече от 30 хиляди абонати, чийто трафик се обработва от 4 NAT сървъра.
INследните версии:
- големи потоци и високопроизводителен оформител;
- големи потоци и високопроизводителна защитна стена.
Hardcore conf в C++. Каним само професионалисти.