Нормальные провайдеры до дома тоже тянут оптику, ставят оборудование на тех. этаже (или в чердаке\подвале), а до абонента тянут линк через слаботочку или через собственные стояки. То есть нормальной сети так же решительно пофиг на грозу как и GPON.
обычный — нельзя, он тупо не будет работать(если мы все еще про GPON). Воткнуть свой роутер после ONT конечно можно, но скорей всего вас не устроят настройки ONT, а поменять их вам никто не даст.
При «overcommit_memory = 0» ОС будет сама решать «выделить или не выделить». И делать это будет на основе прошлого поведения ПО, а не на основе того, что в коде ребенка сказано. Во всяком случае я именно так понимаю фразу на kernel.org и это согласуется с тем, что я видел на практике (если раньше бинарник запрашивал память и использовал ее, и сейчас он запрашивает еще, при том что физически столько нет, то вполне может получить NULL на свой malloc. В конце концов не просто так ведь везде пишут «проверяйте возвращаемые значения»).
vm.overcommit_memory обычно выставлен в 0. Это примерно значит «ОС не выделит виртуальной памяти(malloc), если ей кажется что она не сможет удовлетворить последующие запросы к этой памяти». Вот чуть подробнее на примере redis'а.
Решается в простейшем случае выставлением vm.overcommit_memory в 1, но нужно понимать что после fork'а (который естественно отработает с применением технологии copy-on-write) может прийти oom_killer, если ребенок или родитель начнут активно изменять память и она фактически закончится.
Кстати в статье есть утверждение:
В ulimits есть максимальный размер памяти, который на Linux не работает, но там же есть ещё максимальный размер виртуальной памяти. Это такая интересная штука, потому что, как я уже говорил, виртуальная память — не ресурс. В принципе, от того, что я зарезервирую 100 Тбайт адресного пространства, операционной системе ни холодно ни жарко. Но ОС скорее всего не даст мне этого сделать, пока я для своего процесса не становлю соответствующий ulimit.
Вот в ней тоже неплохо бы сделать оговорку про vm.overcommit_memory mi5ha6in
В статье не рассматривается никакой конкретной VPN-технологии. Единственное требование: что бы на двух устройствах были совместимые VPN-сервер и VPN-клиент.
Наличии реального ipv4 в данном случае совершенно не обязательно, но ваш VPN-клиент должен уметь соединяться с вашим VPN-сервером, для этого может быть использован реальный ipv4 адрес на одном из концов (либо на vps, либо «дома»), проброс необходимых портов, реальный ipv6 адрес или что-то типа того, главное что бы ваши сервер и клиент смогли соединиться.
"$cidr->add("$1") if (/^\s*(\d+\.\d+\.\d+\.\d+\/\d+)\s*$/)" — в этой строке выбираются только входящие строки в формате «ip/mask», но не просто «ip». То есть условный «192.168.0.5/24» в итоговую выборку попадет, а условный «192.168.1.1» будет просто откинут без всякого суммирования.
Если переписать скрипт вот так(что бы одиночные ip без маски тоже обрабатывались):
#!/usr/bin/perl
use Net::CIDR::Lite;
my $cidr = Net::CIDR::Lite->new;
while (<STDIN>) {
chomp;
$cidr->add("$1") if (/^\s*(\d+\.\d+\.\d+\.\d+\/\d+)\s*$/);
$cidr->add_ip("$1") if (/^\s*(\d+\.\d+\.\d+\.\d+)\s*$/);
$cidr->add_range("$1-$2") if (/^\s*(\d+\.\d+\.\d+\.\d+)\s*-\s*(\d+\.\d+\.\d+\.\d+)\s*.*$/);
}
print "$_\n" for $cidr->list;
То результат станет порядка 62к адресов, из которых подавляющая часть с масками /29, /30, /31 и /32, а всех остальных меньше 200 штук.
Например, достаточно легко сделать суммаризацию списка ip-адресов через решения на perl или python. Простой скрипт на perl, делающий это с помощью Net::CIDR::Lite, превращает 85 тысяч префиксов в 60 (не тысяч), но, естественно, перекрывает гораздо бОльший диапазон адресов, чем заблокировано.
Вот этот момент я немножечко не понял.
Я набросал скрипт на перле:
То есть что бы получить заявленные вами 60 маршрутов (или около того), нужно суммировать маршруты с масками /6. Тут скорей всего ошибка где-то в расчетах (или у вас, или у меня).
1) Ваш вариант удаляет «все одиночные адреса» из выгрузки, оставляет только «забанненое по подсетям» (grep '/')
2) этот пайп можно ужать до одного вызова awk: awk -F ';' '{split($1, arr, " | "); for (i in arr) {if (arr[i] ~ /\//) addr[j] = arr[i] ; j++ }} END {PROCINFO["sorted_in"] = "@val_num_asc"; asort(addr) ; for (i in addr){print "/ip firewall address-list add comment=\"Fuck RKN\" list=rkn address="addr[i]}}'
3) Если есть условно 3 микротика и одна VPS, то в вашем варианте адреса нужно пушить в каждый микротик, а в варианте из статьи только один раз в bird на VPS, на конечные микротики маршруты доедут сами через BGP.
4) Ваш вариант только добавляет адреса и не удаляет старые. Метод в статье позволит перестать гнать трафик через тунель в случае если адрес пропал из выгрузки (нее, я понимаю что с практической точки зрения на данный момент это так себе агрумент, но тем не менее).
не забудьте для своего маленького роутера привести маленькую стоечку (потому что в нормальные стойки ставиться только оборудование, предназначенное для установки в стойку, и кол-во и перечень оборудования прописываются в договоре, то есть приехать и просто засунуть в стойку свой роутер вам скорей всего не разрешат), маленький источник питания (потому что питать из рабочей стойки непонятно что и непонятно зачем опять же в нормальных местах не дадут), маленький дизель (ну это ж цод, тут так принято) и главное непонятно зачем это все.
В ЦОД люди ездят что бы выполнить работы, которые невозможно выполнить удаленно. Обычно это «монтаж, демонтаж, замена аппаратного обеспечения». Сетап ОС, настройку, обновление и прочие работы, которые вы собираетесь делать с ноутом «не сидя в шумном зале» вполне можно сделать до или после посещения ЦОДа из дома или офиса. Для этого в серверах существуют ipmi/ilo/idrac, а в ЦОДах клиентам предоставляют ipkvm (отдельное физическое устройство, которые выполняет роль монитора\клавиатуры\мышки через интернет"
держать данный чемоданчик конечно лучше же в ЦОДе, ведь выезжать вы будете не из дома или из офиса, а оттуда, где вас застанет данная неприятность. К тому же может оказаться что выехать в ЦОД сегодня удобно вашему коллеге, а не вам.
Для этого есть спец. ящики, типа таких, крепятся в стойку, как обычное оборудование, закрываются на ключ.
В случае, если у вас несколько цодов, то желательно идет такой чемоданчик в каждом из них.
(речь конечно же про случаи, когда количество железа в цоде не «около нуля», и цод для работ вы посещаете более менее регулярно. В случае «у вас 2 сервера, и вы были в цоде 3 года назад при установке серверов и год назад диск меняли» держать такой чемоданчик в цоде наверное не действительно не стоит).
Нет, не правильно. Arpwatch отслеживает связи "соответствие IP адреса мак-адресу" и в логи пишется "все новые пары, все пропавшие пары и изменившиеся пары". Кто, как и кому назначает ip адреса arpwatch не знает, его интересует только пара "ip-mac" в пакете, дошедшем до него.
Кстати раз пошла такая пьянка: arpwatch нужно или в условном центре сети ставить, или сливать на него копию трафика, если его поставить где то "в углу сети на сервере который ничего не делает" то его показатели будут мягко говоря "не самыми актуальными"
ЗЫ: а статья эта, она о чем вообще? Прочитать — прочитал, а что и кому хотел сказать автор так и не понял
Простаивающий резервный канал — это проявление вопиющей некомпетентности.
Не всегда. У нас например канал в интернет — Х денег, резерв «в простое» Y денег, использование резерва Z денег (Y меньше, чем Z).
При этом простаивающий резерв — не выключен, а по нему гоняется трафик на уровне «статистической погрешности». Это позволяет нам с одной стороны быть уверенными что резерв у нас в рабочем состоянии (хоть и «простаивает» большую часть времени), а с другой стороны не переплачивать за резевр пока работает «более дешевый» основной канал. Резервный канал конечно периодически тестируем на предмет «выдержит ли полную нагрузку».
Так что не стоит так однозначно вешать ярлыки.
Зы понимаю что у нас не совсем стандартная ситуация, но у многих может быть примерно так же: «дешевый местный провайдер» в качестве основного провайдера, и «мобильный, ограниченный по трафику» канал в качестве резерва.
Решается в простейшем случае выставлением vm.overcommit_memory в 1, но нужно понимать что после fork'а (который естественно отработает с применением технологии copy-on-write) может прийти oom_killer, если ребенок или родитель начнут активно изменять память и она фактически закончится.
Кстати в статье есть утверждение:
Вот в ней тоже неплохо бы сделать оговорку про vm.overcommit_memory mi5ha6in
udevadm monitorдолжен показать
Наличии реального ipv4 в данном случае совершенно не обязательно, но ваш VPN-клиент должен уметь соединяться с вашим VPN-сервером, для этого может быть использован реальный ipv4 адрес на одном из концов (либо на vps, либо «дома»), проброс необходимых портов, реальный ipv6 адрес или что-то типа того, главное что бы ваши сервер и клиент смогли соединиться.
Если переписать скрипт вот так(что бы одиночные ip без маски тоже обрабатывались):
То результат станет порядка 62к адресов, из которых подавляющая часть с масками /29, /30, /31 и /32, а всех остальных меньше 200 штук.
Вот этот момент я немножечко не понял.
Я набросал скрипт на перле:
Поиграл значением переменной mask в теле и получил такие значения:
32 | 85929
31 | 70875
30 | 57153
29 | 46442
28 | 38231
27 | 31421
26 | 25805
25 | 21129
24 | 17616
23 | 14353
22 | 11645
21 | 9495
20 | 7740
19 | 6251
18 | 5056
17 | 4053
16 | 3204
15 | 2543
14 | 1947
13 | 1465
12 | 1069
11 | 750
10 | 505
9 | 329
8 | 189
7 | 103
6 | 56
5 | 28
4 | 14
3 | 7
2 | 4
1 | 2
0 | 1
То есть что бы получить заявленные вами 60 маршрутов (или около того), нужно суммировать маршруты с масками /6. Тут скорей всего ошибка где-то в расчетах (или у вас, или у меня).
2) этот пайп можно ужать до одного вызова awk:
awk -F ';' '{split($1, arr, " | "); for (i in arr) {if (arr[i] ~ /\//) addr[j] = arr[i] ; j++ }} END {PROCINFO["sorted_in"] = "@val_num_asc"; asort(addr) ; for (i in addr){print "/ip firewall address-list add comment=\"Fuck RKN\" list=rkn address="addr[i]}}'3) Если есть условно 3 микротика и одна VPS, то в вашем варианте адреса нужно пушить в каждый микротик, а в варианте из статьи только один раз в bird на VPS, на конечные микротики маршруты доедут сами через BGP.
4) Ваш вариант только добавляет адреса и не удаляет старые. Метод в статье позволит перестать гнать трафик через тунель в случае если адрес пропал из выгрузки (нее, я понимаю что с практической точки зрения на данный момент это так себе агрумент, но тем не менее).
В ЦОД люди ездят что бы выполнить работы, которые невозможно выполнить удаленно. Обычно это «монтаж, демонтаж, замена аппаратного обеспечения». Сетап ОС, настройку, обновление и прочие работы, которые вы собираетесь делать с ноутом «не сидя в шумном зале» вполне можно сделать до или после посещения ЦОДа из дома или офиса. Для этого в серверах существуют ipmi/ilo/idrac, а в ЦОДах клиентам предоставляют ipkvm (отдельное физическое устройство, которые выполняет роль монитора\клавиатуры\мышки через интернет"
Для этого есть спец. ящики, типа таких, крепятся в стойку, как обычное оборудование, закрываются на ключ.
В случае, если у вас несколько цодов, то желательно идет такой чемоданчик в каждом из них.
(речь конечно же про случаи, когда количество железа в цоде не «около нуля», и цод для работ вы посещаете более менее регулярно. В случае «у вас 2 сервера, и вы были в цоде 3 года назад при установке серверов и год назад диск меняли» держать такой чемоданчик в цоде наверное не действительно не стоит).
Нет, не правильно. Arpwatch отслеживает связи "соответствие IP адреса мак-адресу" и в логи пишется "все новые пары, все пропавшие пары и изменившиеся пары". Кто, как и кому назначает ip адреса arpwatch не знает, его интересует только пара "ip-mac" в пакете, дошедшем до него.
Кстати раз пошла такая пьянка: arpwatch нужно или в условном центре сети ставить, или сливать на него копию трафика, если его поставить где то "в углу сети на сервере который ничего не делает" то его показатели будут мягко говоря "не самыми актуальными"
ЗЫ: а статья эта, она о чем вообще? Прочитать — прочитал, а что и кому хотел сказать автор так и не понял
В чем смысл им продавать, а кому то покупать сертификат на домен, которым человек и так владеет?
Есть. EV SSL за 349 это как раз сертификат для домена.
Об этом много написано, только в документации сторонних продуктов, например в zabbix: https://www.zabbix.com/documentation/3.4/ru/manual/installation/known_issues
Форум заббикса по ключевым словам выдает много тем с одним и тем же решением, так что не вы первый и не вы последний :)
Уточните пожалуйста что именно вы имеете ввиду? В чем состоит неправда?
Не всегда. У нас например канал в интернет — Х денег, резерв «в простое» Y денег, использование резерва Z денег (Y меньше, чем Z).
При этом простаивающий резерв — не выключен, а по нему гоняется трафик на уровне «статистической погрешности». Это позволяет нам с одной стороны быть уверенными что резерв у нас в рабочем состоянии (хоть и «простаивает» большую часть времени), а с другой стороны не переплачивать за резевр пока работает «более дешевый» основной канал. Резервный канал конечно периодически тестируем на предмет «выдержит ли полную нагрузку».
Так что не стоит так однозначно вешать ярлыки.
Зы понимаю что у нас не совсем стандартная ситуация, но у многих может быть примерно так же: «дешевый местный провайдер» в качестве основного провайдера, и «мобильный, ограниченный по трафику» канал в качестве резерва.