qemu guest를 둘러보던 중 아주 이상한 점을 발견했습니다. 게이트웨이로 향하는 모든 트래픽을 거부하도록 시스템 방화벽을 설정하면( 10.0.2.2), 방화벽은 게이트웨이로 직접 이동하는 트래픽만 거부합니다. 목적지가 아닌 것으로 보이는 트래픽은 10.0.2.2마치 규칙이 존재하지 않았던 것처럼 계속 라우팅되고 게이트웨이를 통해 흐릅니다.
고객의 입장에서 제가 이해한 바에 따르면 ( 10.0.2.15):
Packet{dest==10.0.2.0/24} 10.0.2.15 -x-> 10.0.2.2 (Rejected)
Packet{dest!=10.0.2.0/24} 10.0.2.15 <--> 10.0.2.2 <-> !=10.0.2.0/24 (Okay)
이것은 내가 기대했던 것과 정확히 반대입니다. 뭔가 빠진 것 같은데, 뭔지 모르겠어요.
이것은 내 설정입니다.
- 방화벽 규칙:
ufw reject out to 10.0.2.0/24 - 출력
ip route:default via 10.0.2.2 dev ens3 proto dhcp metric 100 10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15 metric 100 - 출력의 관련 부분은
iptables -S다음과 같습니다.-A ufw-user-output -d 10.0.2.0/24 -j REJECT --reject-with icmp-port-unreachable
답변1
이는 유효하며 게이트웨이가 소스 및 대상 IP 주소에 대한 패킷을 라우팅하므로 차단되지 않습니다.아니요게이트웨이의 주소입니다. 아니요IPv4주소가 10.0.2.2인 패킷(ARP에 대한 아래 참조)은 IP 주소가 10.0.2.2/24인 게이트웨이를 통해 성공적으로 라우팅하는 데 사용됩니다.
따라서 10.0.2.15가 8.8.8.8로 패킷을 보낼 때 패킷의 소스 주소는 10.0.2.15이고 대상 주소는 8.8.8.8입니다. 패킷에는 대상 10.0.2.2가 없으므로 10.0.2.0/24 범위에는 대상이 없습니다. 통과.
게이트웨이를 통해 라우팅되는 페이로드와 관련된 유일한 간접적인 방법은 IPv4 주소가 10.0.2.2인 패킷이 IPv4 패킷이 아니라는 것입니다. 그들은ARPVM 시스템이 게이트웨이 인터페이스의 이더넷 MAC 주소를 검색(및 해당 ARP 테이블에 캐시)하는 데 사용하는 패킷입니다. IPv4 트래픽 "외부": 경로가 게이트웨이와 일치하고 링크 계층(이더넷)에서 이 MAC 주소(IP 주소 10.0.2.2 대신)로 전송됩니다.
ARP는 필터링되지 않습니다.iptables이것은 UFW 백엔드이므로 UFW에 의해 차단될 수 없습니다. 그것은 관련이있을 수 있습니다arp 테이블예를 들어 유용한 사용 사례는 흔하지 않습니다.
노트
동적 호스트 구성 프로토콜(IPv4)
10.0.2.2가 가상 머신의 DHCP 서버이기도 한 경우, 이는 사용된 특정 기술에 따라 향후 특정 시점에 DHCP 통신이 제대로 작동하지 못하게 하거나 가상 머신이 브로드캐스트 DHCP 검색을 수행하도록 강제할 수도 있고 그렇지 않을 수도 있습니다. 유니캐스트 DHCP 요청 대신. 몇 시간 후에 임대가 손실될 수 있는 경우 IP 주소도 손실되어 라우팅되므로 라우터를 통해 간접적으로 연결됩니다.
일반적으로 Linux의 DHCP는 모든 소스 주소를 우회하는 RAW 소켓(예: 소스 주소 0.0.0.0을 올바르게 처리)에 의존해야 하기 때문에 일반적으로 그렇지 않습니다.iptables규칙.
IPv6
IPv6의 링크 레이어 해결 프로토콜은 ARP가 아니라ICMPv6 사용따라서 IPv6의 일부이며 필터링되었습니다.IP6 테이블, IPv4에 유효한 일부 가정은 IPv6에는 유효하지 않습니다. 예를 들어, ICMPv6을 무분별하게 차단하면 IPv6 연결이 급격히 끊어지고 다음을 통해 얻은 라우팅 가능한 IPv6 주소가 제거되는 경우가 많습니다.SLAAC, IPv4를 무차별적으로 차단하는 ICMP는 일반적으로 잘 작동하지만(가능한 경우 제외)PMTUD 블랙홀 문제).