같은 홈 서버에서 두 개의 VPN을 경로 충돌 없이 사용할 수 있나요?

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

예, 두 개의 VPN은 주소, 경로, 기본값, 방화벽 규칙 및 반환 경로가 명확히 분리되어 있을 때 하나의 홈 서버를 공유할 수 있습니다.

문제는 두 터널이 동일한 사설 서브넷을 주장하거나, 경쟁하는 기본 경로를 설치하거나, 중복된 인터페이스 또는 테이블 식별자를 사용하거나, DNS를 전역적으로 재작성하거나, 요청과 다른 터널을 통해 응답을 보낼 때 발생합니다. 안전한 설계는 먼저 각 VPN에 원격 액세스, 상업용 출구 등 명확한 목적을 할당한 후, 한 터널만, 다른 터널만, 그리고 두 터널을 함께 테스트하면서 각 작업 부하에 대한 활성 경로를 기록하는 것입니다.

두 VPN을 시작하기 전에 각 VPN의 역할 정의하기

VPN A와 VPN B에 속하는 클라이언트, 목적지, 프로토콜 및 애플리케이션을 기록하세요. 일반적인 설계는 원격 NAS 액세스를 위한 하나의 WireGuard 서버와 선택된 컨테이너를 위한 하나의 상업용 VPN 출구를 포함합니다.

OpenVPN 커뮤니티는 여러 터널을 동시에 실행할 수 있지만, 각 인스턴스는 별도의 가상 어댑터, 포트 및 중복되지 않는 고유 서브넷이 필요하다고 명시합니다.

두 터널 모두 서버의 모든 트래픽을 전달할 의도라면, 어느 것이 주(primary)이고 어느 것이 백업 또는 중첩(nested)인지 결정하세요. 두 개의 독립적인 “모든 트래픽 전송” 정책은 명확한 순서 지정 없이는 동일한 패킷을 동시에 제어할 수 없습니다.

터널과 원격 LAN 서브넷을 고유하게 유지하기

두 터널의 주소 풀, 광고된 모든 원격 LAN, 홈 LAN, 컨테이너 네트워크 및 일반 원격 클라이언트 네트워크를 비교하세요. 동일한 라우팅 컨텍스트 내에서 두 개의 다른 장소를 참조하는 목적지는 없어야 합니다.

OpenVPN의 HOWTO는 중복된 사설 네트워크가 라우팅 모호성을 일으키는데, 이는 시스템이 중복된 주소가 어떤 사이트를 나타내는지 알 수 없기 때문이라고 설명합니다. 고유한 접두사는 중복 주소 모호성을 제거하여 경로 메트릭이 고려되기 전에 문제를 해결합니다.

가능하면 한 터널 또는 LAN의 번호를 변경하세요. 중복이 불가피하다면, 제어된 NAT 변환, 별도의 네트워크 네임스페이스, VRF 또는 정책 테이블을 사용하고 마지막에 시작된 터널에 의존하지 마세요.

두 VPN이 기본 경로를 교체하지 않도록 방지하기

VPN이 없는 상태, VPN A만 활성, VPN B만 활성, 두 VPN 모두 활성 상태에서 라우트 테이블을 검사하세요. 기본 경로, 0.0.0.0/1128.0.0.0/1과 같은 분할 기본 경로, 메트릭, 두 VPN 서버에 대한 호스트 경로를 기록하세요.

OpenVPN 티켓에서는 관리자가 경쟁하는 기본 경로를 결정하지 않는 한, 여러 VPN을 통해 기본 게이트웨이를 리디렉션하는 것은 유용하지 않다고 지적합니다.

선택된 서브넷에만 서비스를 제공해야 하는 터널에서는 자동 기본 경로 설치를 비활성화하세요. 두 번째 터널을 올릴 때 제어 연결이 첫 번째 터널로 들어가지 않도록 각 VPN 제공자 엔드포인트로 가는 경로를 기본 WAN을 통해 유지하세요.

출발지 또는 애플리케이션별 트래픽에 정책 라우팅 사용하기

각 VPN을 통해 나가야 하는 트래픽에 대해 별도의 라우팅 테이블을 만들고, 출발지 서브넷, 컨테이너 주소, 방화벽 마크, 사용자 또는 인터페이스별로 선택하세요. 일반 홈 서버 트래픽은 기본 테이블에 유지하세요.

Unix 및 Linux의 다중 VPN 연결 예시는 각 인터페이스에서 나오는 트래픽이 자신의 라우팅 테이블을 사용하고 올바른 모뎀 또는 터널을 통해 반환되도록 규칙을 권장합니다.

문서화된 순서로 규칙을 추가하고 대표적인 출발지와 목적지 쌍에 대해 경로 조회를 테스트하세요. 연결된 LAN과 반환 경로가 없는 정책 테이블은 선택된 애플리케이션을 나머지 홈 네트워크와 격리할 수 있습니다.

NAT, 방화벽, DNS 및 반환 경로 정렬하기

각 VPN에 대해 어떤 인터페이스가 트래픽을 전달하는지, 어떤 출발지 주소가 마스커레이드되는지, 어떤 인바운드 서브넷이 허용되는지, 클라이언트가 받는 DNS 해석기가 무엇인지 문서화하세요. 원격 쪽에 반환 경로가 없는 경우에만 NAT를 적용하세요.

Server Fault 사례에서는 WireGuard 클라이언트를 OpenVPN 연결을 통해 라우팅할 때, 원격 VPN이 OpenVPN 클라이언트 주소만 알고 원격 WireGuard 클라이언트 서브넷을 모를 수 있으므로 트래픽에 마스커레이딩이 필요할 수 있다고 설명합니다.

응답이 세션을 수신하거나 시작한 터널을 통해 나가는지 확인하세요. 비대칭 응답은 VPN이 연결된 것처럼 보이지만 TCP, DNS 또는 SMB 트래픽이 조용히 실패하게 만들 수 있습니다.

운영 환경 사용 전 실패 및 재시작 순서 테스트하기

VPN A를 시작한 후 VPN B를 시작하고, 순서를 반대로 하며, 각 서비스를 독립적으로 재시작하고, 서버를 재부팅하세요. 경로, 규칙, DNS, 방화벽 상태 및 기존 원격 관리 액세스가 유지되는지 기록하세요.

ZimaSpace의 하나의 누락된 VPN 경로 복구 가이드는 한 터널이 실수로 다른 터널의 트래픽을 가로챘을 때 복구 순서를 제공합니다.

구성은 두 터널이 어떤 지원되는 순서로든 재연결되고, 각 작업 부하가 의도한 경로를 따르며, DNS가 예측 가능하고, 한 VPN을 비활성화해도 관리 트래픽이 고립되지 않을 때만 안전합니다. 두 서비스를 부팅 시 자동화하기 전에 로컬 콘솔 또는 비VPN 복구 경로를 유지하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.