집 VPN 서버와 클라우드 서버: 어느 쪽이 당신의 NAS에 닿는가?

터널은 올라오고 클라이언트는 초록 점을 보여 주는데, ssh 192.168.1.20 여전히 타임아웃이 될 때까지 매달려 있다. 작은 클라우드 인스턴스를 빌려 WireGuard를 올린 뒤 나는 정확히 이것을 겪었다. 핸드셰이크는 정상, DNS도 정상인데 책상 위 NAS는 달에 있는 것처럼 닿지 않았다. 터널에는 아무 문제가 없었다. endpoint가 내 집으로 가는 경로가 없는 네트워크에 놓여 있었던 것이다. endpoint 위치가 어떤 네트워크와 인접하는지를 결정하므로, 먼저 만져야 할 자원으로 고르고 호스팅은 두 번째로 비교하라.

터널은 endpoint가 경로를 설정할 수 있는 네트워크에만 닿는다

VPN은 클라이언트에 endpoint 자신의 라우팅 도메인 안 주소를 준다. 클라이언트가 192.168.1.20으로 패킷을 보내면 endpoint는 그 목적지를 알아야 한다. 클라우드 VM의 표는 공급자의 VPC 서브넷만 알고, 당신의 LAN은 들어 본 적이 없다. 연결됨과 도달 가능함은 다른 사실이며, 집과 클라우드 사이의 혼란 대부분은 전자를 후자의 증거로 여기는 데서 온다.

명령 하나면 판가름 난다. endpoint에서 ip route get 192.168.1.20 는 LAN 인터페이스를 지목하거나 기본 경로를 가리킨다. 집 기기라면 답은 LAN 쪽이다. 클라우드 인스턴스라면 패킷은 인터넷으로 나가 죽는다. net.ipv4.ip_forward=1 를 켜고 MASQUERADE 규칙을 더해도 달라지지 않는다. 집 쪽의 무언가가 클라우드로 가는 링크를 끝내기 전에는 전달할 곳이 없기 때문이다.

집의 경우에는 후반부가 있다. 돌아오는 경로다. 터널 상자를 지나 LAN을 떠나는 패킷은 NAT되거나, LAN이 터널 서브넷으로 가는 정적 경로를 필요로 한다. 한 방향만 동작할 때는 sysctl net.ipv4.conf.all.rp_filter 를 확인하라. 엄격한 역경로 필터링은 경로가 예측한 것과 다른 인터페이스로 도착한 응답을 버리며, 증상은 방화벽 규칙과 똑같아 보인다.

설정을 건드리기 전에 증상을 읽어라

터널이 안 맺어지면 키, endpoint 주소, 막힌 UDP 포트다. 터널은 올라오는데 LAN 호스트가 죽었으면 배치와 라우팅이다. 터널은 올라오는데 브라우징이 죽었으면 포워딩, NAT, DNS다. 이것은 세 계층과 세 가지 다른 점검이며, 이미 맞는 설정을 다시 쓰는 것은 저녁 하나를 버리는 일이다.

집으로 들어오는 도달성은 따로 점검할 가치가 있다. 집 호스팅이 애초에 가능한지를 결정하기 때문이다. 공유기가 보고하는 WAN 주소와 외부 호스트가 보는 주소를 비교하라. 그것이 100.64.0.0/10에 들어가거나 둘이 어긋나면 당신은 통신사급 NAT 뒤에 있고, 어떤 포트 포워딩도 결코 동작하지 않는다. 실제 선택지는 릴레이, 집에서 바깥으로 거는 클라우드 링크, 또는 endpoint를 옮기는 것이다.

집 호스팅이 주는 것과 그 대가

집은 기본적으로 LAN 안에 있는 유일한 배치이며, 서버를 거기 두는 이유는 그것뿐이다. 프린터나 비로컬 서브넷을 거부하는 NAS 관리 페이지처럼 로컬 세그먼트에서만 응답하는 기기도 추가 라우팅 없이 동작한다. 기기와 공유기, 상향 회선도 직접 운영한다.

대가는 물리적이다. 집 업로드는 모든 클라이언트가 동시에 쓰는 상한이라 화상 통화와 백업이 같은 관을 두고 다툰다. 전력, 디스크 마모, 패치, DDNS 가 필요한 동적 주소, 안쪽으로 UDP를 포워딩해야 하는 공유기, 그리고 어쩌면 이중 NAT까지 모두 당신 몫이다. 사람들이 빠뜨리는 것은 복구다. 집을 비운 사이 상자가 죽으면 집으로 들어가는 유일한 길도 함께 죽는다. 같은 키를 가진 두 번째 기기를 두거나, 최소한 물리적 접근 계획을 세워라.

집에 상자 없이 LAN 접근을 원한다면 흉내 내지 말고 링크를 만들어라. 클라우드 endpoint가 라우터가 된다. 집 쪽에서 AllowedIPs = 192.168.1.0/24 를 붙인 터널을 클라우드 peer에 걸고, 클라우드 상자에서 포워딩과 NAT를 한다. strongSwan의 포워딩 안내서가 그 구성의 귀환 절반을 설명하며, 바로 거기서 이런 시도의 대부분이 실패한다. 이제 집 peer가 살아 있어야 무엇이든 동작하므로, 의존성 하나를 다른 것으로 바꾼 셈이며 그것을 적어 두어야 한다.

클라우드 endpoint는 실제로 무엇을 위한가

클라우드 endpoint는 공인 출구를 바꾼다. 트래픽은 공급자의 주소 범위에서 나가고, 사이트는 집 주소 대신 그 주소를 본다. 가치가 거기에 있으며, 클라우드 VPN이 NAS를 주지 않는 이유도 같다. 옮긴 것은 출구이지 LAN이 아니다.

게스트 시스템과 VPN 서비스, 그 자격 증명은 당신이 운영하고, 하이퍼바이저와 물리 네트워크는 공급자가 운영한다. 새벽 2시에 무언가 깨질 때 이 분담이 중요하다. 공인 endpoint는 계속 스캔되므로 관리 포트를 닫고 VPN 포트만 허용하며 일정에 따라 패치하라. 보안 그룹과 공급자 방화벽이 그 포트를 허용해야 하고, 일부 클라우드는 인스턴스의 출발지·목적지 검사를 조정하지 않으면 포워딩된 트래픽을 버린다.

작은 인스턴스는 몇몇 클라이언트를 감당하지만 암호화는 CPU 작업이고, 크레딧이 바닥난 버스터블 인스턴스는 지속 부하에서 고르지 않게 행동한다. 스펙 표가 아니라 실제로 쓰는 경로를 보라.

적어 둘 수 있는 결정

배치를 정하는 것은 상자의 라벨이 아니라 작업이다. 집 LAN의 기기에 닿아야 한다면 가장 싼 정답은 집의 endpoint이며, 클라우드 상자는 귀환 링크를 만든 뒤에야 동작한다. 다른 공인 출구가 필요하면 답은 클라우드이고 LAN 질문은 생기지 않는다. 둘 다 원하는 것은 정당하지만, 두 endpoint와 두 키 세트, 두 문서화된 경로를 뜻한다.

클라이언트에서 순서대로 확인하라. 핸드셰이크, peer 주소, LAN 호스트, 그다음 출구 IP다. curl -s https://ifconfig.me 는 인터넷이 보는 것을 보여 주고, ip route get 192.168.1.20 는 endpoint가 믿는 것을 보여 준다. 출구 점검이 통과하고 NAS 점검이 매달리면 배치에 대한 답은 이미 있다. 클라이언트의 AllowedIPs를 조정해도 경로가 생기지 않는다. 10.8.0.0/24, 192.168.1.0/24 같은 분할 줄은 그 경로가 실제로 존재할 때만 LAN 트래픽을 터널 안에 둔다.