플로우테이블을 사용할 때 "flow offload" 문을 어떻게 구성해야 합니까?

플로우테이블을 사용할 때 "flow offload" 문을 어떻게 구성해야 합니까?

흐름 테이블nftables연결이 설정되면 일반적인 전달 경로를 건너뛰는 "빠른 경로"로 트래픽을 오프로드하는 기능 입니다 . 플로우 테이블을 설정하려면 두 가지를 구성해야 합니다. 첫 번째는 flowtable테이블의 일부로 정의된 자체입니다. 성명서 에 이어 flow offload이것이 제 질문입니다. 매뉴얼 nft페이지에는 다음과 같이 나와 있습니다.

FLOW STATEMENT
    A flow statement allows us to select what flows you want to accelerate
    forwarding through layer 3 network stack bypass. You have to specify
    the flowtable name where you want to offload this flow.

    flow add @flowtable

이것위키 페이지다음과 같은 전체 구성 예가 포함되어 있습니다.

table inet x {

    flowtable f {
        hook ingress priority 0; devices = { eth0, eth1 };
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # offload established connections
        ip protocol { tcp, udp } flow offload @f
        ip6 nexthdr { tcp, udp } flow offload @f
        counter packets 0 bytes 0

        # established/related connections
        ct state established,related counter accept

        # allow initial connection
        ip protocol { tcp, udp } accept
        ip6 nexthdr { tcp, udp } accept
    }
}

이것이 내가 혼란스러워하는 곳입니다. 이 예에서는 트래픽과 it에 ip protocol { tcp, udp }대해 accept동일한 조건( )을 사용합니다 flow offload. 스트림 이 스트림 테이블에 flow offload암시적으로 추가되어 이러한 조건이 항상 일치해야 하기 때문입니까 ? accept아니면 이 예는 단지 우연의 일치이며 accept규칙이 더 엄격할 수 있습니까?

구체적으로 에서 인바운드 SSH 트래픽만 전달 eth0하고 트래픽 오프로드를 활성화한다고 가정해 보겠습니다. 포워딩 체인을 이렇게 구성해야 하나요?

    chain forward {
        type filter hook forward priority 0; policy drop;

        # offload established connections
        ip protocol { tcp, udp } flow offload @f

        # established/related connections
        ct state established,related counter accept

        # allow initial connection
        iif eth0 tcp dport 22 accept
    }

아니면 이런 것? ( flow offload규칙이 변경되었을 뿐입니다)

    chain forward {
        type filter hook forward priority 0; policy drop;

        # offload established connections
        iif eth0 tcp dport 22 flow offload @f

        # established/related connections
        ct state established,related counter accept

        # allow initial connection
        iif eth0 tcp dport 22 accept
    }

답변1

먼저 위키에서 몇 가지 핵심 문장을 지적하고 싶습니다.

스트림 표현식을 통해 순방향 체인에서 오프로드할 스트림을 선택할 수 있습니다.

상태가 생성되면 트래픽이 오프로드됩니다. 이는 일반적으로 첫 번째 응답 패킷이 흐름 테이블 항목을 생성한다는 것을 의미합니다. 초기 트래픽을 허용하려면 방화벽 규칙이 필요합니다. 순방향 체인의 흐름 표현식은 초기 연결의 반환 흐름과 일치해야 합니다.

더 구체적으로 말하면 다음과 같습니다.

이는 또한 특별한 IP 규칙을 사용하는 경우 해당 규칙이 원래 트래픽뿐만 아니라 응답 패킷 트래픽과도 일치하는지 확인해야 함을 의미합니다.

경험상 응답 방향, 설정, 초기화 등을 결정하는 것이 너무 어렵습니다.

또한 그들의 예에서 그들의 설명에 세심한 주의를 기울이십시오. 프로세스 설명은 설정된 로드를 오프로드하고 더 나아가 초기 연결을 수락해야 합니다.

제 생각에는 오프로드는 일반적으로 좋은 것이므로 다음과 같은 광범위한 프로세스 설명을 사용합니다.

ip6 nexthdr { tcp, udp } flow add @f counter
ip protocol { tcp, udp } flow add @f counter

그런 다음 정상적으로 들어오고 나가는 것을 허용합니다.

ct state established,related counter accept
iif $DEV_INSIDE counter accept
iif $DEV_OUTSIDE ip6 daddr <mail server> tcp dport { smtp } counter accept

스트림 문은 그렇게 보일 수도 있지만 확실히 모든 것을 받아들이는 것은 아닙니다. 위의 ASCII 다이어그램을 보면 더 이해가 될 것입니다.

파블로 네이라 아유소(Pablo Neira Ayuso)는 다음과 같이 지적합니다.약간 다른 방식:

흐름이 설정된 상태가 되면 "흐름 오프로드" 작업은 연결 추적 정의를 기반으로 흐름 항목을 추가합니다. 우리는 교통이 양방향으로 가는 것을 보았습니다. 따라서 흐름의 초기 패킷만 기존 전달 경로를 따릅니다.

전체적으로, 예, flow add설명에서 더 구체적으로 설명할 수 있지만 최종 트래픽이 ESTAB 상태를 따르는 데 왜 귀찮게 해야 하며 보호를 유지하기 위해 다른 곳에서 정상적인 상태 저장 규칙을 사용할 수 있습니다.

이 리소스그것은 또한 꽤 깊고 흥미진진합니다.

첫 번째 예를 사용한 다음 nmap스캔하여 다시 확인하겠습니다. 또한 를 사용하여 성공 여부를 확인할 수 있습니다 conntrack -L.

관련 정보