VPN 클라이언트는 연결되지만 인터넷이 없다: 세 가지 빠진 조각

ping에 응답하는 터널에도 전달, 변환, 전달 규칙이 필요합니다. 클라이언트를 다시 편집하기 전에 세 가지 중 무엇이 빠졌는지 확인하세요.

클라이언트는 주소를 받고, 서버는 ping에 응답하며, 그래도 모든 페이지가 시간 초과됩니다. 대부분의 사람들은 이 지점에서 클라이언트 프로필을 편집하기 시작하지만, 이는 보통 헛수고입니다: 터널이 올라오면 서버는 라우터처럼 동작해야 합니다. 패킷이 나가고 응답이 돌아오려면 세 조건이 동시에 성립해야 하며, 어느 것이 빠져도 증상은 같습니다.

작동하는 터널에 여전히 출구가 없는 이유

커널은 인터페이스 사이에서 패킷을 전달해야 하며, 이는 대부분의 Linux 배포판에서 기본적으로 꺼져 있습니다. 트래픽은 외부 세계가 응답할 수 있는 주소로 변환되어야 하며, 모든 상류 라우터가 터널 서브넷으로 돌아가는 경로를 이미 알고 있다면 예외입니다. 방화벽의 전달 경로는 응답을 포함해 양방향 트래픽을 허용해야 합니다.

이들 각각은 따로 고칠 수 있고, 바로 그것이 함정입니다. 변환 규칙 없이 전달을 켜면 패킷은 사설 출발지와 돌아갈 경로 없이 나갑니다. 전달 규칙 없이 변환을 추가하면 커널이 한 단계 뒤에 패킷을 버립니다.

그러므로 클라이언트가 아니라 세 계층을 시험하고, 결과가 의미를 가지려면 한 번에 하나씩 바꾸세요.

전달은 영구적으로 만들어야 하는 커널 스위치

변경하기 전에 현재 값을 확인하고, 설정한 뒤 변경이 적용되었는지 확인하세요.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

첫 번째 명령은 현재 값을 보고하고, 두 번째는 실행 중에 설정하며, 세 번째는 쓰기가 작동했음을 증명합니다. 실행 중 값은 다음 재부팅에서 사라지므로, 설정을 바꾸지 않았는데도 유지보수 후 작동하던 세션이 깨질 수 있습니다.

/etc/sysctl.d/ 아래의 파일에 영구적으로 저장하고, 확인하기 위해 재부팅하는 대신 그 파일을 적용하세요. FreeBSD에서 해당하는 것은 net.inet.ip.forwarding이며, 영구성을 위해 rc.conf의 gateway_enable=YES를 사용합니다. 전달이 비활성화되었다고 보고하는 장치는 «패킷은 오는데 아무것도 돌아오지 않는다»는 보고 부류 전체를 설명합니다. 업그레이드할 때마다 설정을 확인하세요, 다시 빌드된 커널이나 교체된 장치 이미지가 아무에게도 말하지 않고 되돌릴 수 있기 때문입니다.

masquerade 또는 고정 변환 주소를 선택하세요

외부 주소가 동적이면 masquerading이 가장 단순한 올바른 형태입니다. 터널 서브넷을 출발지로, 외부 인터페이스를 출구로 지정하세요.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

공인 주소가 고정이면 바로 그 주소로의 출발지 변환이 더 예측 가능하고 감사하기 쉽습니다.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

두 번째 형태에는 유지보수 함정이 있습니다: 나중에 바뀌는 하드코딩된 주소는 터널을 작동시킨 채로 인터넷 접속을 조용히 멈춥니다. masquerade를 쓰거나, 공급자가 회선을 옮길 때마다 규칙을 갱신하세요. 인터페이스도 중요한데, 상류 터널을 공유하는 라우터는 물리 WAN이 아니라 그 터널로 변환해야 합니다.

필터 테이블이 세 번째 관문

전달과 변환이 모두 올바르더라도 패킷이 필터 테이블에서 죽을 수 있습니다. ufw는 흔한 범인입니다: 전달 정책이 DROP으로 제공되며, 그 한 설정이 트래픽을 죽이는 동안 나머지 구성은 완벽해 보일 수 있습니다. 그것을 올리는 것은 체크박스가 아니라 의도적인 보안 결정입니다.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

첫 규칙은 터널에서 외부로 가는 새 트래픽을 허용하고, 둘째는 응답만 돌아오게 합니다. 둘 다 터널 서브넷과 의도한 목적지로 좁히세요, 터널 인터페이스에서의 포괄적 허용은 인증할 수 있는 누구에게나 VPN을 열린 출구로 만들어 주기 때문입니다.

브리지된 터널은 다른 답이 필요합니다. 주소는 물리 포트가 아니라 브리지에 속하므로 인터페이스를 종속시키면 이전 주소가 사라지고, 브리지 자체가 dhclient br0가 제공할 수 있는 주소를 받을 때까지 호스트는 도달 불가능해 보입니다. 그 실패는 VPN 문제처럼 보이지만 둘째 계층 문제입니다. 방화벽을 만지기 전에 브리지 자체의 주소를 확인하세요, 필터 변경으로는 보낼 주소가 없는 호스트를 고칠 수 없기 때문입니다.

페이지가 절대 로드되지 않을 때 볼 곳

서버의 터널 주소로 ping을 보내 터널이 있음을 증명하세요. 그다음 클라이언트에서 공인 주소로 traceroute를 실행해 어디서 멈추는지 읽으세요: 서버에서 멈추면 패킷은 도착하지만 전달되거나 변환되지 않고, 서버 너머에서 멈추면 문제는 상류에 있고 당신 손 밖입니다.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

첫 명령은 터널이 서버 자체까지 트래픽을 운반함을 증명하고, 둘째는 패킷이 외부로 얼마나 멀리 가는지 보여 줍니다. 터널 주소에서 끝나는 경로는 서버의 전달이나 변환을 가리키고, 한 홉 뒤에 멈추는 경로는 공급자나 상류 라우터의 복귀 경로를 가리킵니다.

서버에서는 클라이언트가 페이지를 로드하는 동안 외부 인터페이스를 관찰하세요. 사설 출발지 주소로 나가는 트래픽은 변환이 빠졌다는 뜻이고, 응답이 전혀 없다는 것은 전달 경로나 상류 복귀 경로가 그것을 버린다는 뜻입니다.

원격 클라이언트가 서버의 LAN 호스트에도 도달해야 한다면, LAN에는 터널 서브넷으로 돌아가는 경로가 필요합니다. 그것은 변환이 아니라 라우팅이며, 인터넷 경로가 마침내 작동한 뒤 가장 자주 잊히는 단계입니다.

관련 글