Распространенное решение состоит в том, что некоторые индексные дескрипторы в корневом каталоге указывают на записи, которые также являются каталогами. Во многих отношениях они аналогичны файлам, но тип файла указывает файловой системе на необходимость интерпретировать их как каталоги.
(В очень старых учебниках, например, для оригинальной Unix, вам даже будет сказано, что вы можете cat
каталог тоже. Обычно это уже не так.)
Другими словами, каждый каталог представляет собой простой линейный список указателей inode. Некоторые из них указывают на листовые узлы в дереве каталогов (файлы), другие указывают на внутренние узлы (другой каталог). Единственное, что является особенным в корневом каталоге, это то, что он является своим собственным родителем, и что есть что-то внешнее по отношению к дереву, которое говорит системе начать обход дерева отсюда.
I think the problem is 81.212.0.0/14 have bigger IP count than 65535, maybe idk.
Возможно, здесь вы совершенно правы. Если вы используете IPset типа hash
, он имеет максимальное количество элементов, которое он может хранить, задается параметром maxelem
при создании IPset... и значением по умолчанию для maxelem
является 65536. И если вы используете хэш типа bitmap
, 65536 адресов — это максимальный размер карты.
Но для чего вы используете IPset? Если вы просто сопоставляете весь сегмент /14, IPset на основе хэша -будет гораздо менее эффективным, чем простое сопоставление на основе сетевого адреса и маски -.
Но если вы только настраиваете начальный набор и планируете в дальнейшем выборочно выбивать из него определенные IP-адреса, то имеет смысл использовать IPset.
Даже в этом случае, если ожидается, что количество выбитых -IP-адресов будет относительно небольшим, может быть целесообразно инвертировать смысл того, что вы делаете, и использовать сопоставление на основе маски -в качестве общего правила. и сопоставление на основе IPset -в качестве исключения.
Что-то вроде:
iptables -N maybeAllow81_212
iptables -A maybeAllow81_212 -m set --match-set denyiplist_81_212 src -j DROP
iptables -A maybeAllow81_212 -j ACCEPT
iptables -A INPUT -s 81.212.0.0/14 -j maybeAllow81_212
Таким образом, любой трафик, поступающий не из сети 81.212.0.0/14, может быть обработан в основной цепочке INPUT с помощью всего двух ассемблерных инструкций :: одной 32-битной -И и одной 32-битной -битовое сравнение. Вы не можете получить намного быстрее, чем это.
Любой трафик из этого сегмента перенаправляется в подцепь maybeAllow81_212
, которая выполняет сопоставление хэша (с инвертированным, надеюсь, гораздо меньшим набором для сопоставления! ), а затем позволить пройти всем, кто не соответствует набору.
Это может быть только потому, что ваш набор allowiplist
имеет типbitmap:ip
(любой из его подтипов -), который допускает не более /16 сетей,или типа hash:ip
(снова любой из его подтипов -)с ограничением по умолчанию в 65535 элементов.
Вы можете увидеть, к какому именно типу относится ваш набор:
ipset -t list allowiplist
Вам скорее нужно использовать (любой из )типов hash:net
ipset, чтобы перейти к сетям ниже /16.
Однако типы hash:net
не принимают истинные диапазоны, такие как, например. 81.212.5.13-81.212.7.4
как битмап :ip или хэш :типы ip.
Можно было бы расширить ограничение hash:ip
типов maxelem, но это не сделало бы эффективного решения.
Поэтому, если вам действительно нужны диапазоны , которые пересекаются за пределами /16 сетей, я бы посоветовал использовать собственный тип соответствия iptables
-m iprange
, если это возможно для вашей общей настройки.