Intereting Posts
Emacs показывает восьмеричные escape-последовательности для некоторых символов в файле UTF-8 Можно ли получить доступ к открытому сеансу терминала gnome в текстовой консоли? Как подключиться к SSH через промежуточный сервер? Как указать общую родительскую папку для файлов tar из разных источников в TrackPoint трудно контролировать после обновления Debian Почему это изменение делает мое блочное устройство недоступным? Запустить rsyslog как непривилегированный пользователь арифметические операции между файлами vte.sh не сохраняет мою директорию gnome-terminal на новой вкладке разница между gnu tar и tar пакетом в хранилищах Fedora DHCP-сервер не включает адреса NTP-серверов в сообщение DHCP ACK Как создать заголовки ядра Linux из ядра ядра Linux? Как скопировать папку другим, но НЕ путем слияния / добавления Масштабирование рабочего стола – kde Выполнять независимые greps в одном сценарии оболочки

(S / D) NAT через NF-крючки

Может кто-нибудь помочь объяснить объяснение преимущества iptables NAT над сетевыми крючками. Предположим, вместо использования NAT, если мы создадим собственный модуль ядра для привязки обработчика с netfilter для управления PRE / POST, тогда, в общем, какой метод (NAT / NF) более оптимизирован или регулируется одним?

Любые ссылки или указатели будут полезны.

Спасибо.!

Согласно документам netfilter:

Netfilter is merely a series of hooks in various points in a protocol stack (at this stage, IPv4, IPv6 and DECnet). The (idealized) IPv4 traversal diagram looks like the following: A Packet Traversing the Netfilter System: --->[1]--->[ROUTE]--->[3]--->[4]---> | ^ | | | [ROUTE] v | [2] [5] | ^ | | v | On the left is where packets come in: having passed the simple sanity checks (ie, not truncated, IP checksum OK, not a promiscuous receive), they are passed to the netfilter framework's NF_IP_PRE_ROUTING [1] hook. Next they enter the routing code, which decides whether the packet is destined for another interface, or a local process. The routing code may drop packets that are unroutable. If it's destined for the box itself, the netfilter framework is called again for the NF_IP_LOCAL_IN [2] hook, before being passed to the process (if any). If it's destined to pass to another interface instead, the netfilter framework is called for the NF_IP_FORWARD [3] hook. The packet then passes a final netfilter hook, the NF_IP_POST_ROUTING [4] hook, before being put on the wire again. The NF_IP_LOCAL_OUT [5] hook is called for packets that are created locally. Here you can see that routing occurs after this hook is called: in fact, the routing code is called first (to figure out the source IP address and some IP options): if you want to alter the routing, you must alter the `skb->dst' field yourself, as is done in the NAT code. 

А также :

 NAT This is the realm of the `nat' table, which is fed packets from two netfilter hooks: for non-local packets, the NF_IP_PRE_ROUTING and NF_IP_POST_ROUTING hooks are perfect for destination and source alterations respectively. If CONFIG_IP_NF_NAT_LOCAL is defined, the hooks NF_IP_LOCAL_OUT and NF_IP_LOCAL_IN are used for altering the destination of local packets. This table is slightly different from the `filter' table, in that only the first packet of a new connection will traverse the table: the result of this traversal is then applied to all future packets in the same connection. Masquerading, Port Forwarding, Transparent Proxying I divide NAT into Source NAT (where the first packet has its source altered), and Destination NAT (the first packet has its destination altered). Masquerading is a special form of Source NAT: port forwarding and transparent proxying are special forms of Destination NAT. These are now all done using the NAT framework, rather than being independent entities.