정책 기반 라우팅(업데이트, SSH 등과 같은 호스트 관련 트래픽을 위한 192.168.1.0/24 관리 네트워크, VM 라우팅을 위한 192.168.2.0/24 DMZ 네트워크)을 사용하여 KVM 가상화 호스트를 설정하고 있습니다.
구성은 이렇습니다(^^^^)위와 같이트리 구조를 나타냄)
#external connectivity
eth0 -> vlan110 -> brhost (192.168.1.9)
^^^ -> vlan120 -> brguest (192.168.2.4)
#internal connectivity
brguestA (10.0.1.1) -> tapA0
^^^ -> tapA1
^^^ -> tapA2
brguestB (10.0.2.1) -> tapB0
^^^ -> tapB1
# ... and so on for each VM group subnet
기계 An은 하나의 "스위치"에 있고, Bn은 두 번째 "스위치"에 있는 식입니다. 호스트는 라우터처럼 동작하며 iptables가 설치되어 있습니다. 소스 IP는 각 브리지의 iptables 수준에서 확인됩니다.
일반적으로 모든 것이 "정상적으로" 작동하지만 일부 특수한 작업을 수행하면 여전히 정상적으로 실행되지만 로그에는 이것이 실제 정상 작동보다 우연의 일치에 가깝다고 나타납니다. 예를 들어:
iptables 수준(tcp-reset)에서 작업이 차단된 가상 머신(관리 네트워크의 다른 호스트)에서 192.168.1.3에 연결하면 다음이 제공됩니다.
(iptables reject log) IN=brguestA OUT=brguest SRC=10.0.1.2 DST=192.168.1.3 ... IPv4: martian source 10.0.1.2 from 192.168.1.3 on dev brhost
호스트/게스트 네트워크 분리 논리를 고려할 때 OUT인터페이스는 실제로 수행해야 할 작업에 따라 정확하며 이러한 패킷이 호스트에 의해 전달되더라도 어쨌든 방화벽에서 삭제됩니다. 그러나 호스트 iptables는 tcp-reset을 제대로 거부하지 않으므로 이러한 연결은 VM에서 중단되고 재설정을 받지 못합니다.
VM에서 192.168.1.9에 연결하면
IPv4: martian source 192.168.1.9 from 10.0.1.2 on dev brguestA
다른 것은 없습니다. 이 로그에서 10.0.1.x와 192.168.1.x의 위치를 바꾸면 정말 혼란스럽습니다. 그 의미(src IP와 dst IP)를 실제로 이해하지 못합니다. 호스트가 무엇을 하려고 하는지, 왜 실패하는지 정말 모르겠습니다. 이것은 내 ip rule결과 입니다 ip route.
ip rule
0: from all lookup local
32763: from 10.0.0.0/16 lookup guest
32764: from 192.168.2.0/24 lookup guest
32765: from all iif lo lookup host
32766: from all lookup main
32767: from all lookup default
ip route show table host
default via 192.168.1.1 dev brhost proto static
192.168.1.0/24 dev brhost proto static
ip route show table guest
default via 192.168.2.1 dev brguest proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ... so on for other networks
ip route show table main
192.168.1.0/24 dev brhost proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ...
systemd-networkd네트워크 관리 용으로 사용하고 있습니다 . 나아이디어이는 호스트가 규칙에 따라 잡기 위해 항상 brhost장치에 설정된 패킷 유형으로 응답하려고 하기 때문에 발생합니다 . OUTPUT그러나 연결이 올바르게 거부되어 항상 출력 소스로 선택되지는 않으므로 이는 사실이 아닌 것 같습니다.iiflofrom iif lookup host192.168.2.4brhost