ebtable 규칙을 사용하면 하나의 규칙에 vlanid 및 ipv4 프로토콜을 지정할 수 없습니다. 나도 이것을 시도했지만 두 번째 규칙은 VLAN 패킷과 일치하지 않았습니다.
ebtables -t nat -A PREROUTING --vlan-id 100 -j mark --set-mark 100 --mark-target CONTINUE
ebtables -t nat -A PREROUTING -i <iface> --mark 100 --ip-dst <ip> -j dnat --to-dst <mac> --dnat-target ACCEPT
두 번째 규칙은 패킷에 VLAN 헤더가 있으면 일치하지 않는다는 것입니다. 일치하는 대상 IP 주소와 VLAN ID를 기반으로 DNAT mac에 대한 방법이 있습니까?
답변1
이는 브리지 필터링에 ebtables를 사용할 때의 현재 제한 사항입니다. ebtables 일치는 일반이 아닌 구체적이며 vlan-plus-ip 일치를 추가하지 않으면 VLAN 태그가 지정된 IP를 다음과 일치시킬 수 없습니다.ebtables.
이 제한 사항을 해결하는 방법에는 두 가지가 있습니다. 첫 번째 접근 방식은 다른 경우에는 많은 작업을 수행하지만 특정 OP의 문제를 처리하지는 않습니다.
브리지 네트워크 필터(이 경우에는 적용되지 않습니다)
많은 경우(실제로는 이 경우는 아님, 아래 참조) 무엇이 관련될 수 있습니까?ebtables'스태킹 프로토콜을 제대로 처리하지 못하면 브리지 코드에 다음 작업을 수행하도록 지시하는 것입니다.업링크 통화도착하다iptables통과br_netfilter 모듈 사용. 글쎄요, 맞습니다.iptables경로/IP 수준이 아닌 브리지 수준에서 작동합니다. 이는 현재 시스템 전반에 걸친 변경 사항이며 다른 브리지 및 기타 네임스페이스(이는 네임스페이스별로 이루어져야 합니다."곧", 아마도 커널 5.3 이후). 일부 의도하지 않은 효과와 이를 방지하는 방법은 에 설명되어 있습니다.7. 프레임/패킷이 iptables PREROUTING, FORWARD 및 POSTROUTING 체인을 통과하는 두 가지 가능한 방법.
modprobe br_netfilter
sysctl -w net.bridge.bridge-nf-call-iptables=1 #actually default
있습니다.VLAN 섹션에 필요한 조치가 없습니다.:
{ip,ip6,arp} 테이블이 태그가 지정되지 않은 브리지에서 VLAN 태그가 지정된 IPv4/IPv6/ARP 트래픽을 볼 수 있습니까?
예. 커널 버전 2.6.0-test7 이상에 이 기능이 있습니다. 이 기능을 비활성화하려면 위의 질문을 참조하세요.
지금ebtables/iptables 상호 작용그럴 수도 있지, 좀 보자5. 브리지된 IP 패킷의 체인 통과. 프레임/패킷에 최소한 다음을 수행하도록 지시합니다.
-> ebtables nat/PREROUTING -> iptables nat/PREROUTING, then
-> ebtables filter/FORWARD -> iptables filter/FORWARD ....
다른 경우도 있지만 필수 항목은 존재하지 않습니다. 동일한 호출 부분으로 돌아갑니다. 예를 들면 다음과 같습니다.
-> ebtables nat/PREROUTING -> iptables some/THING -> ebtables nat/PREROUTING
따라서 OP의 특정 레이아웃(두 번째 규칙의 인터페이스 역할 및 MAC 주소의 의미, 로컬인지, 로컬이 아닌지 등)에 따라 다르지만 몇 가지 옵션이 남아 있을 수 있습니다(필요함). 패킷 전송으로 표시됨) 메시지ebtables도착하다iptables), 방법이 없습니다.
이것이 바로 ebtables/iptables 대안이 처음부터 이러한 모든 혼란을 피하기 위해 설계된 이유입니다.nftables.
nftables
대안nftables일반적인 사용법을 염두에 두고 설계하면 브리지 경로나 라우팅 경로에서 IP를 처리할 때 동일한 작업을 수행하기 위해 약간 다른 커널 모듈에 의존할 필요가 없습니다.
nftables는 움직이는 대상이므로 대부분의 기능을 얻으려면 nftables >= 0.8.3 및 커널 >= 4.10을 사용하는 것이 가장 좋습니다. 이는 nftables 0.9.0 및 커널 5.1.x를 사용하여 테스트되었습니다. 이전 nftables/커널(예: RHEL7/CentOS7)에는 필요한 모든 기능이 없을 수 있으므로 다시 테스트해야 합니다.
이 특정 사례에는 여전히 몇 가지 제한 사항이 있지만 사용자 공간에 있는 것으로 보입니다.nftables커널 측이 아닌 측에서 발생하므로 이를 극복할 수 있는 두 가지 방법을 제공했습니다.
파이프를 추가해 보겠습니다(예: a 뒤에 nft flush ruleset).
nft add table bridge nat
nft add chain bridge nat prerouting '{ type filter hook prerouting priority -300; policy accept; }'
일치하는 IP가 192.0.2.1이고 대상 MAC이 이면 02:00:00:00:00:01일반적으로 이 줄로 작업을 수행하기에 충분합니다(nftables 버전에 따라 다소 장황해야 하지만 어쨌든 장황함을 선택했습니다. 어쨌든 정확히 동일한 바이트를 생성합니다) 코드가 단순화된 버전으로 표시됨) 그러나 실패합니다.
# nft add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 ether daddr set 02:00:00:00:00:01
Error: conflicting protocols specified: vlan vs. ether
add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 ether daddr set 02:00:00:00:00:01
^^^^^^^^^^^
이것nftables사용자 수준 도구는 다음을 따른 후 하위 수준 프로토콜의 구문 분석으로 돌아가기를 원하지 않습니다.이더넷->VLAN->IP.
이 문제는 사용자 체인에서 규칙을 분리하고 거기에 변경 사항을 적용하여 해결할 수 있습니다.
nft add chain bridge nat mydnat
nft add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 jump mydnat
nft add rule bridge nat mydnat ether daddr set 02:00:00:00:00:01
아니면 말함으로써nftables"이것을 하세요. 이해하려고 하지 마세요"는 원래 페이로드를 사용하여 링크 레이어의 처음 48비트를 변경하라는 의미입니다(예:이더넷 대상 MAC). 따라서 이 줄은 위의 3줄 대신 동일한 작업을 수행합니다.
nft add rule bridge nat prerouting ether type vlan vlan id 100 vlan type ip ip daddr 192.0.2.1 @ll,0,48 set 0x020000000001
후자의 메서드는 실제로 후자의 세 번째 줄이 아닌 동일한 바이트코드를 사용한다는 점에 유의하세요.
nft add rule bridge nat mydnat @ll,0,48 set 0x020000000001
ether daddr set 02:00:00:00:00:01체인에 규칙을 표시할 때 정확히 동일하게 다시 디코딩됩니다.미드넛. 미래 버전을 상상할 수 있습니다.nftables단일 안감 상자로 접수됩니다.
작성된 대로 작동한다는 것을 보여주기 위해(예: ARP에 대한 추가 규칙이나 OP 등의 컨텍스트 없이는 예상대로 작동하지 않을 수 있음) 다음은 192.0.2.1에서 ping을 수신할 때 수신 측의 tcpdump입니다.
14:03:06.542085 9e:72:8c:20:15:2a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.0.2.1 tell 192.0.2.2, length 28
14:03:06.542135 ae:3a:24:06:a7:da > 9e:72:8c:20:15:2a, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.0.2.1 is-at ae:3a:24:06:a7:da, length 28
14:03:06.542184 9e:72:8c:20:15:2a > 02:00:00:00:00:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.0.2.2 > 192.0.2.1: ICMP echo request, id 21702, seq 1, length 64
다른 IP 192.0.2.11은 영향을 받지 않습니다.
14:11:04.026480 9e:72:8c:20:15:2a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.0.2.11 tell 192.0.2.2, length 28
14:11:04.026491 ae:3a:24:06:a7:da > 9e:72:8c:20:15:2a, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.0.2.11 is-at ae:3a:24:06:a7:da, length 28
14:11:04.026505 9e:72:8c:20:15:2a > ae:3a:24:06:a7:da, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.0.2.2 > 192.0.2.11: ICMP echo request, id 21895, seq 1, length 64
14:11:04.026515 ae:3a:24:06:a7:da > 9e:72:8c:20:15:2a, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.0.2.11 > 192.0.2.2: ICMP echo reply, id 21895, seq 1, length 64