웹 호스팅과 VPS: 그 플랜으로 VPN 서버를 돌릴 수 있을까
공유 호스팅, 관리형 앱, 직접 관리하는 서버는 네트워크 통제권이 다릅니다. 무엇이든 사거나 이전하기 전에 네 가지 역량을 비교하세요.
돌아가는 웹사이트는 제공자가 HTTP를 서비스할 수 있다는 증거이지, 당신이 기계를 통제한다는 증거가 아닙니다. 공유 플랜, 관리형 애플리케이션, 직접 관리하는 서버 사이에는 계정이 네트워크에 무엇을 할 수 있는지에 큰 간극이 있습니다. 한 해를 더 결제하기 전에 VPN 설계에 그 간극의 어느 쪽이 필요한지 정하세요. 네 가지 역량이 둘을 가르며, 그중 어느 것도 가격표에 나오지 않습니다.
각 플랜이 실제로 주는 것
쓸모 있는 비교는 가격이나 디스크 크기가 아니라 권한입니다. 계정이 무엇을 시작할 수 있는지, 어떤 커널 기능에 닿는지, 어떤 포트가 들어오는 트래픽을 받는지, 허용된 트래픽이 다시 다른 곳으로 나갈 수 있는지 물으세요.
대부분의 호스팅 제품은 세 가지 형태로 나뉘고, 마지막 것만 범용 서버입니다:
| Capability | Website plan | Self-managed server |
|---|---|---|
| Long-running custom process | Usually not permitted | Yours to run under a service manager |
| Virtual network interface | Almost never available | Present when the kernel module and privilege allow it |
| Arbitrary inbound port | Restricted to the web stack | Provider filtering still applies |
| Forwarding for clients | Not offered | Possible once routing and policy are configured |
셸 계정은 흔한 혼동의 원천입니다. 파일 전송이나 예약 작업 접근이 관리처럼 보일 수 있지만, 프로세스는 한 디렉터리와 소수의 허용된 작업으로 제한됩니다.
답을 결정하는 네 가지 역량
첫 단계에서 실패하면 나머지가 무의미해지므로 순서대로 보세요.
첫째, 소프트웨어가 유지보수를 견디는 장기 프로세스로 돌고, 둘째, 구현이 자체 가상 인터페이스를 만들 수 있어야 합니다. Linux에서는 보통 관련 관리 권한으로 /dev/net/tun을 여는 것을 뜻하며, 커널 TUN/TAP 문서가 설명하듯, 모든 VPN 설계가 그 장치를 쓰는 것은 아닙니다. 셋째, 클라이언트가 공인 주소에서 리스너에 닿아야 하고의도한 전송과 포트로도 닿아야 합니다. HTTPS를 받는 웹 리버스 프록시는 같은 번호의 무관한 프로토콜에 대해 아무 말도 하지 않으며, 넷째, 허용된 트래픽은 라우트, 포워딩, 실제로 지원되는 변환을 갖추고 계속 나아갈 수 있어야 합니다.
서비스 약관은 그 네 가지 옆에 있으며 전혀 기술적이지 않습니다. 무제한 트래픽 한도는 보통 웹 요청을 뜻하지, 다른 사람의 다운로드를 나르는 터널을 뜻하지 않습니다. 그 주변을 설계하기 전에 허용되는 사용 항목을 읽고, 서비스가 시작되지 않는 날을 위해 복구 접근을 기억하세요.
웹사이트 계정이 멈추는 지점
웹사이트 플랜은 보통 고정 진입점이 있는 관리형 런타임 안에서 코드를 실행합니다. 터널 바이너리가 있어도 프로세스에 장치 노드를 열거나 특권 포트를 묶거나 라우팅 테이블을 바꿀 권한이 없을 수 있습니다. 그 제한은 제품의 일부이지 실수가 아닙니다.
그래서 VPN을 약속하는 플러그인은 대개 다른 곳으로 가는 프록시로 드러납니다. 현재 계정이 웹사이트 조작만 제공한다면 정직한 방법은 별도 서버이지, 빠진 권한을 여는 모듈을 찾는 것이 아닙니다.
호스트 하나가 둘 다 돌려야 할 때
공유는 가능하고 때로 합리적이지만, 편의가 아니라 보안 결정으로 다루세요. 업로드 양식이 있는 웹 애플리케이션은 터널 자격 증명과 제어 소켓 옆에 있고, 한쪽의 취약점이 다른 쪽에 닿습니다. 계정, 서비스 단위, 파일 시스템을 나누면 두 번째 기계를 사지 않고 그 노출을 줄일 수 있습니다.
자원 경쟁도 그만큼 중요합니다. 터널을 통한 백업과 바쁜 웹 프로세스는 같은 업링크와 같은 디스크를 두고 다투며, 장애는 포화된 터널이 아니라 느린 사이트처럼 보입니다. 사고 전에 어느 부하가 이길지 정하고, 웹사이트가 계속 응답하도록 터널에 상한을 두세요.
두 서비스가 돌아간다는 이유만으로 어느 배치도 격리되지 않습니다. 둘을 함께 호스팅할 수 있는 능력이 설계의 시작이고, 격리 작업이 그것을 방어 가능하게 만듭니다.
시험용 호스트에서 네 명령으로 결판내세요
이전하기 전에 대상 제품의 가장 작은 인스턴스를 한 시간 빌려 네 가지 역량을 직접 시험하세요. 기능표에서 추측하는 것은 잘못된 플랜의 한 해보다 돈은 덜 쓰지만 시간은 훨씬 많이 씁니다.
시험용 호스트에서 이것들을 실행하고 실패를 장애물이 아니라 답으로 읽으세요:
ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | head처음 두 줄은 터널 장치가 애초에 존재할 수 있는지를 알려 줍니다. 셋째 줄은 호스트가 패킷을 전달할 수 있는지 보고하고, 넷째 줄은 이미 무엇이 듣고 있는지 보여 주어 포트 충돌을 일찍 잡습니다. 둘째 줄에서 실패하는 제공자도 사용자 공간 구현을 지원할 수 있으므로, 지원 데스크에 물을 때는 제품 분류가 아니라 필요한 메커니즘을 말하세요.