nginx가 깨지기 전에 OpenVPN SNAT 규칙 범위를 좁히세요

같은 종류의 호스트에서 두 가지 장애가 계속 들어옵니다. 첫 번째에서는 클라이언트가 인증된 뒤 터널 밖으로 아무것도 도달하지 못합니다. 두 번째에서는 VPN이 올라오고 서버 자체의 웹사이트가 응답을 멈추는데, 이는 곁가지 피해처럼 보여 더 우려스럽습니다. 컨테이너 기반 VPS에서는 둘 다 보통 같은 짧은 점검 목록으로 돌아가며, 순서가 중요합니다. 먼저 장치, 다음 변환, 마지막 범위입니다.

컨테이너가 tun 장치를 만들 수 있는지 확인하세요

터널 인터페이스가 존재할 수 없다면 다른 것은 중요하지 않습니다. /dev/net/tun 이 있는지 그리고 테스트 장치 생성이 성공하는지 확인하세요. 많은 공급자가 컨테이너 안에서 tun 을 기본적으로 비활성화하기 때문입니다. 한 번도 만들어진 적 없는 장치를 어떤 firewall 작업도 보상하지 못합니다.

장치가 없다면 호스트나 공급자만이 활성화할 수 있습니다. 다른 요금제가 일주일 동안 이어지는 열린 지원 스레드보다 저렴한 경우가 많습니다. OpenVPN 로그를 한 줄이라도 읽기 전에 이것을 확인하세요. 그렇지 않으면 패킷을 절대 보지 못할 규칙을 조정하며 저녁을 보내게 됩니다.

이 인터페이스에서 MASQUERADE가 무엇을 하는지 결정하세요

일반적인 가상 머신에서는 보통의 이그레스 규칙이 메인 인터페이스에서 POSTROUTING MASQUERADE 나갑니다. OpenVZ 컨테이너에서 보이는 장치는 흔히 venet0 이며, 라우팅된 NIC가 아니라 호스트가 관리하는 가상 인터페이스이고, MASQUERADE는 그곳에서 튜토리얼이 가정하는 대로 항상 동작하지는 않습니다.

실행 가능한 형태는 클라이언트가 이미 도달하는 주소로의 명시적 변환이며, 양방향 전달이 허용됩니다. 서버 구성에서 풀을 바꾸는 것은 주소를 바꾸는 것만큼 중요합니다. 붙여 넣기 전에 각 줄을 읽으세요.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

전달 규칙이 없으면 변환은 여전히 일어나고 커널은 여전히 전달을 거부합니다. 이 조합은 NAT 규칙의 카운터는 올라가는데 클라이언트는 아무것도 받지 못하는 혼란스러운 상태를 만듭니다. 두 FORWARD 줄도 같은 체인에서 어떤 광범위한 drop 규칙보다 앞에 있어야 합니다. 순서는 구성의 일부이며 구현 세부 사항이 아닙니다.

규칙을 하나의 풀과 하나의 인터페이스로 좁히세요

두 번째 증상은 원인이 다릅니다. 소스 제한도 출력 제한도 없는 POSTROUTING 규칙입니다. 그런 규칙은 호스트를 떠나는 모든 패킷을 다시 씁니다.

원래 소스에 의존하는 서비스가 그다음 잘못 동작합니다. 로컬 프록시 뒤의 웹 서버가 응답을 멈출 수 있고, 규칙이 여전히 경로에 있으므로 재시작해도 아무것도 바뀌지 않습니다. 호스트가 자신의 공인 주소로 보내는 트래픽도 영향을 받으며, 그래서 장애가 firewall이 아니라 DNS나 인증서 문제처럼 보일 수 있습니다. 이 규칙은 거의 확실히 첫 번째 증상을 고치기 위해 추가되었습니다.

해결책은 일치 조건을 터널 풀과 이그레스 인터페이스로 좁힌 다음, 여러 개를 덮기 위해 하나의 규칙을 넓히는 대신 풀마다 규칙 하나를 추가하는 것입니다.

규칙을 영구화하고 누가 또 그것을 소유하는지 알아내세요

손으로 추가한 규칙은 재부팅 시 사라지므로 iptables-save 로 저장하거나 설치된 곳에서 netfilter-persistent 로 관리하세요. 복원이 OpenVPN 시작 전에 실행되는지 확인하세요. 그런 다음 인시던트 중에 틈을 발견하는 대신 일부러 한 번 재부팅하세요.

컨테이너 호스트에서는 영속성 파일이 쓰기 가능한 컨테이너 스토리지에 있고 공급자가 부팅 시 필터링을 교체하지 않는지도 확인하세요. 일부 플랫폼은 컨테이너 외부에서 정책을 관리하며, 그곳에서는 로컬 규칙이 무시되거나 호스트 자체 규칙과 충돌합니다.

카운터와 캡처한 흐름 하나로 검증하세요

연결된 클라이언트에서 외부 서비스가 보고하는 공인 주소를 확인하세요. 서버 주소와 일치하면 변환이 작동하고, 그렇지 않으면 패킷이 다른 경로로 나가거나 전혀 나가지 않습니다. 그런 다음 서버에서 호스팅되는 서비스와 공용 인터넷의 서비스를 모두 시험해 보세요. 같은 규칙 집합을 지나지만 경로가 다르기 때문입니다.

서버에서 iptables -t nat -L -v -n 로 NAT 및 FORWARD 규칙의 패킷 카운터를 읽고 캡처에서 흐름 하나를 관찰하세요. 캡처에 클라이언트 주소가 나타나고 응답이 이어지지 않으면, 틈은 반환 경로나 공급자 필터링에 있으며 클라이언트 프로필에는 없습니다. 캡처한 소스를 규칙이 변환하는 주소와 비교하세요. 불일치는 다른 규칙이 먼저 일치했음을 뜻합니다. 관찰한 흐름 하나는 구성 한 페이지를 읽는 것보다 많은 것을 판정합니다.

풀, 변환된 주소, 인터페이스 이름을 변경 기록에 함께 보관하세요. 한 풀에 맞는 규칙은 다음 풀을 잘못 변환합니다.