PiVPN 핸드셰이크는 되는데 페이지가 멈춘다면: MASQUERADE를 확인하세요

휴대폰은 터널을 연결됨으로 표시하고 클라이언트도 사설 주소를 보고하는데, 첫 페이지는 여전히 로딩 중간에서 멈춰 있습니다. 이 조합은 대부분의 사람을 암호 설정과 CPU 온도 쪽으로 보내지만, 실제로 그곳에는 잘못된 것이 없습니다. 터널은 올라왔으니 협상은 끝났고, 실패한 것은 그다음 단계, 서버가 클라이언트 패킷을 인터넷으로 넘기려는 부분입니다. 그 패킷이 지나는 경로를 그대로 따라가면 불일치는 보통 NAT 테이블 한 줄에서 드러납니다.

클라이언트가 도달할 수 있는 것과 없는 것부터 시작하세요

연결된 클라이언트에서 공용 인터넷에 있는 페이지를 불러오고, 즉시 실패하는지 중간에서 멈추는지 확인하세요. 그다음 VPN 서버 자체의 사설 주소에 있는 리소스를 열고 두 결과를 비교하세요.

공용 사이트는 시간 초과되는데 ping에는 응답하는 터널 주소는 전달이나 변환 문제의 신호이지, 망가진 핸드셰이크의 신호가 아닙니다. 클라이언트 자체의 상태 패널은 둘을 구분하지 못합니다, 제어 채널이 올라와 있다는 것만 알기 때문입니다. 서버에서 터널 인터페이스를 다음으로 확인하세요: ip -br addr show tun0 그리고 클라이언트에 할당된 주소가 설정한 풀 안에 있는지 확인하세요. 풀과 클라이언트 주소가 어긋나면 먼저 그것을 고치세요, 아래의 모든 규칙이 풀을 기준으로 일치하기 때문입니다.

다음으로 서버에 공용 주소에 도달할 때 어느 인터페이스를 쓸지 물어보세요. ip route get 203.0.113.9 첫 줄에 선택된 장치와 소스를 출력합니다. 그 장치 이름을 적어 두세요, NAT 규칙에 들어가야 하는 값이 바로 그것입니다.

패킷이 나가는지를 결정하는 규칙을 읽으세요

MASQUERADE는 패킷이 규칙에 적힌 인터페이스로 나갈 때만 패킷을 다시 씁니다. 유선 장치에 한정된 규칙은 Wi-Fi로 나가는 트래픽에 아무 효과가 없고, 패킷은 상위 라우터까지 사설 소스 주소를 유지합니다. 그 라우터에는 터널 풀로 돌아갈 경로가 없으므로 응답을 버리고, 클라이언트는 열렸다가 곧 죽는 연결을 보게 됩니다. 증상은 첫 응답이 필요할 때까지 페이지가 얼마나 도착하는지에 따라 커집니다.

활성 테이블을 나열하고 MASQUERADE라는 단어만 찾는 대신 출력 인터페이스 열을 읽으세요. 형식이 지정된 목록보다 추가 형식의 출력이 비교하기 쉽습니다:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

한때 Ethernet을 쓰고 지금은 Wi-Fi를 쓰는 Raspberry Pi에서는 오래된 이름이 거의 항상 전부입니다. 설치 프로그램이 설정 당시 어떤 장치가 있었는지 기록했고, 저장된 규칙 세트가 부팅할 때마다 그것을 다시 재생합니다. 다른 것을 바꾸기 전에 라우트 조회에서 나온 장치와 규칙에 있는 장치를 비교하세요. 둘이 일치하면 인터페이스는 문제가 아니며 마지막 절의 카운터로 넘어가야 합니다. 다르면 수정은 영속성 파일에서 한 단어를 고치는 것입니다.

저장된 규칙 세트를 고치세요(실행 중인 것만이 아니라)

활성 테이블만 편집하면 다음 재부팅까지만 유지되지만, 그것만으로도 문제가 해결됐다고 믿기에는 충분합니다. 부팅 시 돌아오는 규칙은 방화벽 영속성 패키지가 다시 불러오는 파일에 있습니다. Debian 기반 Pi 이미지에서 그 파일은 보통 /etc/iptables/rules.v4.

건드리기 전에 복사본을 만들고, MASQUERADE 줄의 출력 인터페이스를 기록한 장치로 바꾸고, 예를 들어 -o wlan0 대신 -o eth0. 클라이언트 풀이 바뀌지 않았다면 소스 범위는 그대로 두세요. 다시 불러오고 규칙이 이제 올바른 장치를 가리키는지 확인하세요:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

인접한 두 설정은 잊기 쉽습니다. sysctl net.ipv4.ip_forward 은 1을 보고해야 하고, 상위 라우터가 사설 소스 주소를 스스로 필터링해서는 안 됩니다.

규칙이 작동함을 증명한 다음, 아직 느린 부분을 분리하세요

카운터가 규칙이 일치했다는 유일한 정직한 증거입니다. 상세 목록을 실행하고, 클라이언트에서 다운로드를 시작한 뒤 다시 실행하세요. 규칙 옆의 패킷과 바이트 열이 올라가야 하고, 영에 머무는 규칙은 아직 일치하지 않습니다. 카운터는 움직이는데 페이지가 계속 실패하면 소스 범위를 실제 풀과 다음으로 비교하세요: grep -n "^server " /etc/openvpn/server.conf. 카운터가 움직이고 페이지도 로드되는데 처리량이 나쁘면 변환은 끝났고 남은 문제는 다른 곳에 있습니다.

같은 클라이언트에서 두 전송을 비교하세요, 하나는 로컬 네트워크의 호스트로 다른 하나는 터널을 거쳐 같은 호스트로 보냅니다. 둘 다 느리면 VPN이 아니라 Pi의 업링크나 Wi-Fi 링크를 가리킵니다. 터널을 거칠 때만 느리면 MTU와 재전송을 가리키며, 이는 다음으로 확인할 수 있습니다 ip -s link show tun0 어떤 암호 설정을 바꾸기 전에.

실험을 되돌리려면 복사본을 복원하고 다시 불러온 뒤, 원래 규칙과 그 카운터가 돌아왔는지 확인하세요. 다음 업링크 변경에서 같은 불일치가 다시 발견되므로 나가는 장치와 다시 불러오기 명령을 서버 메모에 적어 두세요. 잘못된 장치를 가리키는 규칙은 트래픽이 필요로 할 때까지 보이지 않습니다.