당신은 Proxmox 방화벽을 웹 UI 및 SSH에서 접근할 수 있는 노드에서 활성화합니다. 개인 VM은 더 이상 인터넷에 접근할 수 없습니다. 경로가 없거나 포워딩이 비활성화되어 있거나 MASQUERADE가 없으면 동일한 증상을 나타냅니다.
규칙을 수정하기 전에 경로, NAT 및 MASQUERADE 규칙을 확인한 다음 DNS를 점검하십시오. 그런 다음 VM의 policy_out과 fwbr+의 conntrack zone의 특정 사례를 확인하십시오. 공식 수정 사항이 모든 NAT 마운트에 해당되지 않으므로 롤백을 준비해 두십시오.
규칙을 변경하기 전에 올바른 시나리오 식별하기
진단은 프라이빗 서브넷에 위치한 VM 또는 CT를 대상으로 합니다. 해당 브리지는 공공 물리 포트를 갖고 있지 않으며 게스트는 Proxmox 노드의 공용 주소를 통해 마스커레이딩 규칙으로 나갑니다.
모든 수정 전에 수행해야 할 작업은 다음과 같습니다:
- 게스트에 개인 IP 주소와 기본 경로가 있는지 확인하십시오;
- NAT가 노드에 존재하고 IPv4 포워딩이 활성화되었는지 확인하십시오;
- 방화벽이 활성화되어 있으며 노드의 웹 UI와 SSH에 접근할 수 있는지 확인하십시오.
VM이 한 번도 정상적으로 출구가 없었다면, 먼저 브리지, 가상 카드 및 게스트 인터페이스로 돌아가십시오. VM의 네트워크를 복구하는 방법, 브리지에서 게스트까지 이 진단의 이 부분을 다룹니다.
방화벽을 비난하기 전에 경로 및 NAT 확인하기
먼저 패킷이 실제로 VM에서 나가는지를 이해해야 합니다. 게스트에서 다음과 같은 default 행을 찾아보십시오:
ip route
ping -c 3 1.1.1.1기본 경로가 없으면 출구가 불가능합니다. 테스트 IP 주소에 대한 핑 실패는 아직 방화벽이 VM을 차단하고 있다는 증거가 아닙니다.
노드에서 포워딩 및 POSTROUTING 체인을 확인하십시오:
sysctl net.ipv4.ip_forward
iptables -t nat -S POSTROUTINGProxmox 문서는 마스커레이딩을 개인 게스트용 POSTROUTING 유형 규칙으로 설명합니다. 예시는 10.10.10.0/24, 출력 인터페이스 eno1, 그리고 MASQUERADE 동작을 사용합니다. 이 값들을 현재 구성에 맞게 조정하되 무작위로 규칙을 교체하지 마십시오.
ip_forward=0, NAT 규칙이 누락되었거나 출력 인터페이스가 잘못된 경우에는 문제가 방화벽을 넘어갑니다. Proxmox 방화벽을 구성하여 접근을 잃지 않기는 노드 자체에 접근 가능성이 문제가 될 때를 위한 답변입니다.
IP 출구, DNS 및 APT 업데이트 분리하기
이 순서로 각 레이어를 테스트하십시오. DNS 해결 실패는 방화벽 차단으로 결론지을 수 없습니다.
ping -c 3 1.1.1.1
getent hosts deb.debian.org
curl -I https://deb.debian.org/- IP 핑 실패: 경로, 포워딩 및 MASQUERADE를 확인하십시오;
- IP 핑 응답: 그러나
getent실패: 게스트 리졸버와 DNS 차단policy_out을 확인하십시오; - 해결이 응답하지만 HTTP 요청이 실패: HTTPS 출구, VM 정책 및 저장소 연결을 확인하십시오;
- 네트워크 출구가 작동하지만 APT 업데이트가 실패: 저장소 및 사용하는 이미지가 확인되기 전에는 NAT를 수정하지 마십시오.
APT 테스트는 Debian 및 Ubuntu 이미지를 대상으로 합니다. 다른 배포의 경우 적합한 패키지 관리자 및 저장소를 사용하십시오. 기대되는 결과는 동일합니다: IP 주소의 고장, 해결 문제 또는 저장소 접근 문제를 구분하는 것입니다.
브리지를 변경하지 않고 OUT 정책 및 Proxmox 로그 확인하기
경로와 NAT가 일관성이 있을 때 게스트의 방화벽 영역으로 넘어가십시오. Proxmox는 Host, VM/CT 및 VNet 영역을 분리합니다. VM의 규칙은 노드를 보호하는 규칙과 같은 곳에서 읽히지 않습니다.
노드에서 규칙의 상태와 컴파일을 표시하십시오:
pve-firewall status
pve-firewall compile그런 다음 /etc/pve/firewall/<VMID>.fw에서 VM 또는 CT 구성을 재확인하십시오. policy_out, log_level_out 및 DNS, NTP 또는 HTTP/HTTPS와 관련된 출력 규칙을 확인하십시오. 로깅이 활성화된 경우 Proxmox 인터페이스의 방화벽 로그도 참조하십시오.
pve-firewall simulate를 사용하면 소스, 목적지, 포트 및 프로토콜을 시뮬레이션할 수 있습니다. 커널의 라우팅 테이블은 시뮬레이션하지 않습니다. 따라서 긍정적인 결과가 NAT의 전체 경로를 확인하는 것은 아닙니다.
VM/CT 규칙, 출력 정책 및 로그의 경우 Proxmox의 VM 또는 CT를 위한 방화벽 규칙도 참조하십시오. 출력 정책을 수정하기 위해 브리지를 변경하지 마십시오.
fwbr+에서 conntrack zone의 공식 사례 확인하기
Proxmox 문서는 특별한 경우를 언급합니다: 특정 마스커레이드 마운트와 방화벽이 활성화된 경우, 외부 연결이 VM의 브리지 POSTROUTING를 MASQUERADE보다 선호할 수 있습니다. 이 경우 차단을 피하기 위해 conntrack zone이 필요할 수 있습니다.
이 수정 사항을 모든 Proxmox NAT에 일반화하지 마십시오. 먼저 raw 테이블에 방화벽 브리지가 있는지 확인하십시오:
iptables -t raw -S PREROUTING | grep 'fwbr'트래픽이 이 시나리오에 해당하면, 공식 문서에서는 해당 네트워크 구성에 다음 두 줄을 제안합니다:
post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1첫 번째 줄은 네트워크가 올라올 때 구역을 추가합니다. 두 번째 줄은 같은 규칙을 떨어뜨릴 때 제거합니다. NAT 경로가 제대로 작동하는 것을 확인한 후 /etc/network/interfaces의 해당 네트워크에 존재하는 스탄자에 추가하십시오.
raw 명령이 fwbr를 보여주지 않고 IP 출구가 이미 작동한다면, zone 1을 강제로 설정하지 마십시오. 대신 경로, NAT, DNS 또는 실패하는 OUT 정책을 찾으십시오.
노드 접근을 손상시키지 않고 수정 사항 테스트하기
네트워크를 재로드하기 전, 두 줄을 눈에 두고 두고 원격 접근이 중단될 수 있는 경우 유지보수 기간을 계획하십시오. /etc/network/interfaces를 수정하기 전에 콘솔 접근 또는 다른 복구 경로를 유지하는 것이 좋습니다.
구성을 적용한 후, 먼저 raw 규칙을 확인한 다음 다음 세 가지 테스트를 VM에서 수행하십시오:
iptables -t raw -S PREROUTING | grep 'fwbr'
ping -c 3 1.1.1.1
getent hosts deb.debian.org
curl -I https://deb.debian.org/IP 출구가 응답해야 DNS를 판단할 수 있습니다. 해결이 응답해야 HTTP 접근 또는 APT 저장소에 대한 결론을 내릴 수 있습니다. 증상이 되돌아오면 추가한 post-up 및 post-down 지시문을 제거한 후 iptables -t raw -S PREROUTING에서 CT --zone 1이 더 이상 나타나지 않는지 확인하십시오.
주의: pve-firewall stop는 Proxmox의 iptables 규칙을 적극적으로 제거하고 호스트를 보호 없이 만들 수 있습니다. 이 명령은 진단을 대신할 수 없으며 NAT 출구를 잃는 개인 VM에 대한 일반적인 해결 방법으로 사용되지 않아야 합니다.
판단은 매우 구체적일 것입니다: 경로, 포워딩, MASQUERADE, DNS 및 OUT 정책이 일관되게 있어야 방화벽을 비난할 수 있습니다. NAT가 fwbr+를 통과한다면, conntrack zone은 타겟 수정을 위한 것이며, 대칭 롤백이 필요합니다. 그렇지 않다면 브리지 진단이나 VM/CT 규칙으로 돌아갑니다.
참조: NAT 및 마스커레이딩에 대한 Proxmox 문서, Proxmox VE 방화벽 문서 및 공식 pve-firewall 매뉴얼.
