VPN을 호스팅하기 전에 VPS가 허용해야 하는 것

인스턴스가 부팅되고 패키지 설치가 성공하며 서비스가 실행 상태까지 보고하지만 아무것도 연결되지 않습니다. 이 패턴은 가상 사설 서버에서 흔합니다. 인터넷에 편하게 닿는 게스트도 프로토콜이 요구하는 인터페이스를 만들지 못할 수 있기 때문입니다. 다섯 가지 확인이 터널을 제공할 수 있는 호스트와 단지 준비된 것처럼 보이는 호스트를 구분하며, 처음 실패하는 확인이 보통 그 뒤의 모든 것을 설명합니다. 각 확인은 실행 비용이 적고 메모가 아니라 결정으로 끝납니다.

프로토콜이 필요로 하는 인터페이스를 확인하세요

OpenVPN TUN 위에서 동작하려면 문자 장치와 그 뒤의 커널 모듈이 필요합니다. WireGuard는 자체 커널 지원이나 기대에 맞는 사용자 공간 구현이 필요합니다. 관리형 컨테이너는 장치를 절대 노출하지 않는 호스트 커널을 공유할 수 있고, 일부 플랫폼은 무엇이 설치되어 있든 터널 인터페이스 생성을 아예 금지합니다.

지원 페이지를 읽는 대신 능력을 시험하세요. 마케팅 라벨은 기반 한계보다 빨리 바뀝니다. 한 요금제를 위해 쓰인 기능 목록은 게스트가 실제로 실행되는 커널을 설명하지 않을 수 있습니다. 두 개의 짧은 명령이 흔히 쓰는 프로토콜에 대한 질문에 답하며, 둘 다 뒤처리를 합니다. 아래 명령은 영구적인 것을 만들지 않고 즉시 제거됩니다.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

첫 쌍에서 거부되면 TUN을 쓸 수 없고 OpenVPN의 기본 모드가 시작될 수 없습니다. 마지막 줄에서 거부되면 WireGuard 커널 인터페이스가 없습니다. 커널 TUN/TAP 문서 는 첫 확인이 시험하는 장치를 설명합니다. 두 실패 중 어느 것도 VPN 패키지를 다시 설치해서 고쳐지지 않습니다.

들어오는 경로에는 소유자가 둘이라는 점을 기억하세요

제공자의 네트워크 규칙과 게스트의 방화벽은 별개의 시스템이며 트래픽은 둘 다 통과해야 합니다. 게스트에 바인딩된 리스너는 제공자의 보안 그룹이 포트를 버리면 아무 의미가 없고, 제공자 규칙이 열려 있어도 게스트가 패킷을 거부하면 아무 일도 일어나지 않습니다. 리스너, 그다음 게스트 규칙, 그다음 제공자 패널 순서로 확인하고 포트 번호와 함께 프로토콜도 확인하세요. 곧바로 제공자 패널로 뛰어드는 것이 필요하지도 않은 범위를 열게 되는 이유입니다.

UDP가 흔한 희생자입니다. 많은 플랫폼이 기본적으로 TCP를 허용하고 UDP 규칙을 별도 항목으로 다룹니다. 인스턴스가 공인 주소를 갖지 않고 제공자의 NAT 뒤에 있다면 제공자 쪽 포트 포워딩이 조정해야 할 세 번째 구성이 됩니다.

나가는 길만이 아니라 돌아오는 경로를 계획하세요

전체 터널 서비스에는 포워딩 활성화, 클라이언트 트래픽을 위한 변환 또는 라우팅 방식, 클라이언트 풀에 도달하는 돌아오는 경로가 필요합니다. 리스너를 여는 것만으로는 이 중 아무것도 얻지 못합니다. 설정되지만 유용한 트래픽을 나르지 않는 터널은 보통 인증이 아니라 여기서 실패합니다. 성공한 핸드셰이크를 진단의 끝이 아니라 시작으로 다루세요.

계획을 세 가지 구체적 결정으로 쓰세요: 클라이언트가 받는 소스 범위, 그들의 트래픽이 인터넷으로 나가는 방식, 응답이 돌아오는 길을 찾는 방식입니다. 그다음 클라이언트를 시험하기 전에 커널이 계획에 동의하는지 확인하세요. 조용한 불일치를 클라이언트 측 결함으로 오해하지 않기 위해서입니다.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6 문제를 명시적으로 결정하세요

IPv6는 게이트웨이에 대해 다르게 동작하는 여러 메커니즘으로 옵니다. 인스턴스의 주소, 라우팅된 프리픽스, 또는 아무것도 없음입니다. 라우팅된 프리픽스만이 서버가 평소처럼 클라이언트에 주소를 줄 수 있게 합니다. 호스트에서 동작하는 IPv6 주소가 곧 쓸 수 있는 클라이언트 프리픽스를 뜻한다고 가정하는 것은 나중에 반쯤 끊긴 연결로 드러나는 오류입니다. IPv4만으로 하는 모든 시험을 통과해 버리는 종류의 결함입니다.

제공자가 어떤 프리픽스도 라우팅하지 않는다면 터널을 IPv4 전용으로 할지, 클라이언트에게 알릴지를 결정하세요. 문서화된 부재는 연결된 사용자에게 IPv6 목적지를 조용히 블랙홀로 보내는 부분 구성보다 안전합니다.

외부 클라이언트에서 증명하세요

로컬 서비스 상태는 한 호스트의 한 프로세스를 설명할 뿐입니다. 유용한 시험은 다른 네트워크의 승인된 클라이언트가 배포하려는 프로필로 연결한 뒤 애플리케이션에 도달하고 이름을 해석하는 것입니다. 한 번은 다시 연결해 보세요. 첫 시도에서만 작동하는 터널은 실무에서 가장 중요한 요구를 충족하지 못합니다.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

시험과 함께 운영의 기본을 유지하세요. 업데이트를 위한 여유, 제한된 로그, 터널에 의존하지 않는 관리 접근, 복구 콘솔, 그리고 인스턴스가 다시 만들어지고 공인 주소가 바뀔 때 클라이언트 프로필이 어떻게 되는지에 대한 기록입니다. 필요한 인터페이스나 포워딩 모델이 아예 없다면 클라이언트 측 변경으로는 채울 수 없고, 정직한 다음 단계는 설정을 더 늘리는 것이 아니라 다른 종류의 인스턴스입니다.