브리지된 OpenVPN 클라이언트에 인터넷이 없나요? NAT 규칙을 확인하세요

브리지된 서버는 켜져 있고 masquerade 규칙도 있는데 클라이언트의 브라우저는 계속 돌고 있습니다. 모두 제대로 동작할 것처럼 보이기 때문에 첫 한 시간은 터널과 자격 증명을 확인하는 데 쓰입니다. 그다음 NAT 규칙의 카운터를 읽으면 움직이지 않은 영이 보입니다. 패킷을 한 번도 세지 않은 규칙은 어떤 패킷과도 일치한 적이 없으며, 브리지된 서버에서 그 이유는 구조적입니다. 클라이언트 트래픽은 가상 tap 장치로 나가는데 규칙은 오래된 안내서에서 복사한 물리 카드를 지정합니다.

증거는 카운터이지 표의 행이 아닙니다

존재하는 규칙과 일치하는 규칙은 다른 것이고, 카운터가 둘을 구분합니다. NAT 표를 자세한 카운터와 함께 나열하고 무엇이든 바꾸기 전에 각 규칙 옆의 숫자를 읽으세요. 트래픽이 흐르는 동안 영에 멈춘 카운터는 규칙이 건너뛰어졌다는 뜻입니다. 주소가 아무리 그럴듯해 보여도 마찬가지입니다. 연결이 계속 실패하는데도 카운터가 올라가면 다른 곳을 보라는 신호입니다. 포워딩, 되돌아오는 경로, 또는 반대편 끝입니다.

iptables -t nat -L POSTROUTING -v -n

먼저 인터페이스 일치 옆의 카운터를 읽으세요. 소스 범위가 맞고 나가는 쪽이 틀렸다면 수정은 완전히 새 규칙이 아니라 규칙 안의 한 단어입니다.

커널이 실제로 기록하는 이름을 찾으세요

규칙을 쓰기 전에 기억이 아니라 인터페이스 목록을 사용해 터널 장치를 이름으로 확인하세요. 브리지된 OpenVPN 구성에서 장치는 보통 서버가 만든 tap 인터페이스이고 그 이름은 로컬 구성의 일부이며 보편적인 상수가 아닙니다. 터널이 켜져 있는 동안 그것이 존재하는지 확인하세요. 클라이언트가 연결된 뒤에야 나타나는 장치는 이전 테스트를 규칙 문제로 보이게 만듭니다.

ip -brief link

이름을 적어 두세요. 이 진단의 이후 모든 명령이 그것을 가리키며, 여기서의 오타는 원래 실수와 똑같은 영 카운터를 만듭니다.

터널 장치에 맞춰 규칙을 다시 쓰세요

규칙을 터널 장치로 향하게 하고 클라이언트 범위를 일치 조건으로 유지해 터널 트래픽을 덮으면서 호스트 자체 연결은 건드리지 않게 하세요. 아래 두 예시는 모두 예시일 뿐이며 설치 간에 옮길 수 없으므로 자신의 범위와 장치 이름으로 바꾸세요.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

그다음 같은 증상이 감추는 다른 두 조건을 확인하세요. 포워딩이 켜져 있는지 보고, 꺼져 있다면 재부팅 때 사라지는 echo가 아니라 배포판 자체의 구성에서 켜세요. forward 체인의 카운터도 읽고, 터널 트래픽을 버린다면 그 인터페이스만 허용하고 체인 정책은 그대로 두세요.

카운터와 함께 forward 체인을 읽는 데는 명령 하나면 되고, 다른 규칙을 건드리기 전에 남은 가능성의 절반을 배제합니다.

물리 카드가 절대 일치하지 않는 이유

브리지는 tap 장치와 물리 인터페이스 하나로 조립된 소프트웨어 스위치입니다. 클라이언트 프레임은 그 스위치로 들어가 카드 위의 패킷이 아니라 브리지의 구성원으로서 물리 네트워크로 나갑니다. 그래서 커널은 패킷을 브리지와 그 포트에 귀속시키고, 생각하던 카드가 일치에 나타나지 않는 이유도 그것입니다. 물리 인터페이스는 고장 난 것이 아닙니다. 다만 커널이 그 패킷을 귀속시키는 장치가 아닐 뿐입니다.

사람들이 다음에 부딪히는 문제도 같은 구조에서 옵니다. 브리지의 프레임 필터링은 IP 필터링과 별개의 기능입니다. 요구 사항이 프레임 수준 제한이라면 그것은 브리지 필터링에 속하며 IP 표 규칙이 아닙니다.

끝에서 끝까지 증명한 다음 영구적으로 만드세요

클라이언트 하나를 올리고 서버 LAN의 무언가에 ping을 보내세요. 그 경로는 변환 없이 포워딩을 연습합니다. 그다음 masquerade 규칙을 반드시 써야 하도록 공개 대상에 요청하고 카운터를 다시 읽으세요. 이 테스트에서는 움직여야 하고 이전 테스트에서는 움직이지 않아야 합니다. 터널 장치에서 뜬 캡처는 프레임이 어디에 나타나고 어떤 주소를 실었는지를 함께 보여 줍니다.

마지막 단계입니다. 동작하는 규칙을 재부팅 때 읽는 구성에 넣고, 이 호스트의 브리지가 실제로 쓰는 장치 이름을 적어 두세요. 손으로 입력한 것은 재부팅 후 사라지고, 같은 고장이 설명할 것도 없이 되돌아옵니다.

다시 쓴 뒤에도 카운터가 움직이지 않는다면 규칙의 소스 범위와 클라이언트가 실제로 받은 주소를 비교하세요. 브리지된 서버는 의도하지 않은 범위에서 주소를 내줄 수 있습니다.