В даній статті розглянемо відключення цих безпекових методів. Що це таке – написано тут. Відключати я це не рекомендується, але в деяких випадках це треба, враховуючи, що продуктивність може досягати до 30%.
В даній статті розглянемо відключення цих безпекових методів. Що це таке – написано тут. Відключати я це не рекомендується, але в деяких випадках це треба, враховуючи, що продуктивність може досягати до 30%.
Знайшов нещодавно досить цікавий проект, який дозволяє використовувати потужності віддаленого сервера, не встановлюючи при цьому ПЗ (програмного забезпечення) на ньому.
Припустимо, у вас є якесь ПЗ, але вам не вистачає потужності поточного серверу, але є інший сервер. При цьому, на іншому потужнішому сервері зовсім не треба ставити це ПЗ, достатньо поставити лише outrun:
pip3 install outrun
Які обмеження при використанні:
Домашня сторінка
Зіштовхнувся з однією проблемою при використанні iptables разом з ipset, а саме, коли перечитуєш правила, отримуєш помилку:
ipset v7.10: Set cannot be destroyed: it is in use by a kernel component
ipset v7.10: Set cannot be created: set with the same name already exists
Експерементальним шляхом було визначено, що після онулення правил неможливо одразу (мабуть, ще висять у памʼяті) видалити записи у ipset, треба зачекати. Тобто, потрібна от така констукція:
Розглянемо ситуацію, коли сервер asterisk’a знаходиться за NAT’ом і треба зареєструватися у SIP провайдера. В 99% випадів, проблем немає, але інколи, нічого не виходить. Більш детальний аналіз показує, що пакети SIP чомусь не NAT’яться. Чому? Відповідь трохи незвична, якщо ви працювали з іншими unix like системами. Деякі протоколи (FTP, SIP, …) використовують 2 сесії для успішної передачі даних: сигнальна (встановлення зʼєднання) і передачі даних. У інших ОС (файерволах) вам потрібно самостійно опікуватися цими проблемами, які додаткові порти відкрити або як переналаштувати зʼєднання (наприклад, перейти з active на passive режим в FTP). В Linux для цього придумали механізм conntrack (connection tracker), який “зазирає” всередину зʼєднання і дозволяє створити відповідне динамічне правило (насправді це правило треба створити окремо, але там ми не вказуємо конкретні порти, просто вказуємо, що це відноситься до, наприклад, SIP і пакети автоматично будуть проходити). Чи це добре? І так і ні. Чому добре – зрозуміло. Чому ні? Тому що, інколи виникають проблеми, про які сказано на початку статті.
BCC is a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and examples. It makes use of extended BPF (Berkeley Packet Filters), formally known as eBPF, a new feature that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1 and above.
bpftrace is a high-level tracing language for Linux enhanced Berkeley Packet Filter (eBPF) available in recent Linux kernels (4.x)
bpftop provides a dynamic real-time view of running eBPF programs. It displays the average runtime, events per second, and estimated total CPU % for each program. It also provides graphical views of these statistics over time. This tool minimizes overhead by enabling performance statistics only while it is active.
Симптомы: часть сайтов открывается, часть – нет. tcpdump показывает нормальное прохождение пакетов в обе стороны. Всему виной PPPoE с его overhead’ом на размер пакета.
Решение простое:
iptables -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Но что оно означает? Оно означает “нормализовать пакет” согласно PMTU, то есть, уменьшить размер MSS так, что бы пакет прошёл от источника к назначению, при этом выбрав наименьший MTU среди всех промежуточных.
Важно! Правило нужно размещать в самом начале.
Расскажу об одной, на первый взгляд, странной проблеме. Основная проблема: после обновления с 10 на 11 через некоторое время интерфейс теряет адрес, полученный через DHCP. Откатываешься (это виртуальная машина, поэтому через snapshot’ы такое легко провернуть) обратно на 10-ку – всё работает. Важный момент: такое наблюдается только с серверами у которых DHCP. Так же, на всех серверах (как статических, так и с DHCP) присутствует и другая проблема: после перезагрузки, сервер отвечает на icmp, но ровно 5 минут недоступны вообще никакие сервисы: ssh, http,…
Раньше приходилось заново копировать после каждого обрыва. Но потом придумали механизм, основанный на bookmark’ах, который позволяет продолжить копирование с места разрыва.
Вводные данные: 2 сервера Linux связаны между собой через OpenVPN туннель. Нужно для части клиентов за одним из концов VPN’a завернуть весь трафик в туннель, то есть, что бы они выходили в интернет не через свой GW, а через удалённый GW, пройдя через VPN.
UPD. В данной схеме есть нюанс: она будет работать, если клиентские машины находятся за хостом, который является OpenVPN-клиентом. В обратном случае, пакеты просто не будут покидать хост, хотя через tcpdump вы их будете видеть. Связано это с особенностями самого OpenVPN’a. Пока не нашёл как это можно решить. Как workaround, можно либо изменить роли клиент-сервер, либо использовать простой туннель или другой тип VPN’a.
Вот как полностью выглядит сообщение об ошибке:
Connection timed out H=alt4.gmail-smtp-in.l.google.com [142.250.157.26]:25 DT=12m19s: SMTP timeout after sending data block (452056 bytes written)
Примечание: число в скобках и сервер гугла может быть любой.