netfilter_ipv4.h내가 이해한 바에 따르면 Linux 커널은 파일의 IPv4 패킷 흐름에 대해 5개의 후크 지점을 정의합니다.
/* IP Hooks */
/* After promisc drops, checksum checks. */
#define NF_IP_PRE_ROUTING 0
/* If the packet is destined for this box. */
#define NF_IP_LOCAL_IN 1
/* If the packet is destined for another interface. */
#define NF_IP_FORWARD 2
/* Packets coming from a local process. */
#define NF_IP_LOCAL_OUT 3
/* Packets about to hit the wire. */
#define NF_IP_POST_ROUTING 4
.. netfilter_ipv6.h같은 설명에 따르면 IPv6에서도 마찬가지인 것 같습니다.
/* IP6 Hooks */
/* After promisc drops, checksum checks. */
#define NF_IP6_PRE_ROUTING 0
/* If the packet is destined for this box. */
#define NF_IP6_LOCAL_IN 1
/* If the packet is destined for another interface. */
#define NF_IP6_FORWARD 2
/* Packets coming from a local process. */
#define NF_IP6_LOCAL_OUT 3
/* Packets about to hit the wire. */
#define NF_IP6_POST_ROUTING 4
netfilter작업이 발생하는 위치를 정의하고 어떤 작업을 수행할 수 있는지 결정하는 방식으로 생각/아키텍처를 구성하는 것이 올바른지 궁금합니다 . 또한 커널에도 중요합니까, 아니면 사용자가 발생할 수 있는 처리 유형을 그룹화할 수 있도록 하기 위해 존재합니까?iptableschainstablestablesiptables
답변1
핵심은 테이블이 다음과 같은 방식으로 그룹화되어 있다는 것입니다.디자인을 위한 계획. 필터링에 대한 모든 규칙이 여기에 있고 모든 NAT 규칙이 여기에 있습니다. 체인은 일련의 규칙이며 기본적으로 체인은 패킷 경로의 특정 지점에서 통과됩니다.
이론적으로는 NAT 테이블 등을 필터링하는 규칙을 추가할 수 있습니다. 하지만 프런트엔드는 이를 방지하고 다음과 같은 메시지를 표시합니다.
"nat" 테이블은 필터링에 사용되지 않으므로 DROP이 금지됩니다.
제 생각에는 체인에 관한 것이고 테이블은 체인을 정리하는 데 도움이 되도록 나중에 고려한 것입니다. 임시적이고 전통적인 사용자 인터페이스 디자인이기 때문에 혼란스럽습니다.