로밍 VPN 클라이언트가 사무실용 서비스를 호스팅할 수 있을까?

사무실 노트북은 집에서 다이얼인해도 사무실에 필요한 무언가를 계속 제공할 수 있지만, 세 가지 별개의 결정이 맞아떨어질 때만 그렇습니다. 터널은 전송이고, 내부 주소는 목적지이며, 정책이 누가 두드릴 수 있는지를 결정합니다. 이 중 하나만 전체 답으로 취급하면 호스트는 핑에 응답하지만 애플리케이션은 결코 연결되지 않는다는 익숙한 불만이 생깁니다. 역할은 같지 않으며, 그 차이가 바로 설계 작업이 자리한 곳입니다.

다이얼인 방향은 서비스 방향에 대해 아무것도 말하지 않는다

클라이언트가 터널을 시작하면, 그것이 존재한 뒤 양방향이 사용할 수 있는 경로가 열립니다. 허브에서 그 클라이언트 쪽으로 새 연결이 들어올 수 있는지는 게이트웨이 정책의 문제이지, 다이얼한 사람의 속성이 아닙니다. 예를 들어 라우팅된 OpenVPN 허브에서는 서버에 클라이언트의 내부 주소로 가는 경로와 피어 관계를 허용하는 포워딩이 필요합니다.

로밍 노트북의 에이전트를 폴링하는 재고 시스템이나, 집의 워크스테이션에서 테스트 API가 필요한 개발자를 떠올려 보십시오. 둘 다 사무실 쪽이 대화를 시작하기를 원하며, 이는 일반적인 클라이언트 대 서버 패턴의 반대입니다.

호스팅형 원격 접속 제품은 이 지점에서 서로 다르며, 그 차이는 결함이 아닙니다. 일부 관리형 서비스 VPN은 그들의 모델이 클라이언트 대 리소스이지 리소스 대 클라이언트가 아니기 때문에 연결된 클라이언트를 향한 비요청 연결을 의도적으로 차단합니다. 동료에게 그들의 노트북이 서버 역할을 할 수 있다고 약속하기 전에 제품의 문서화된 아키텍처를 읽으십시오.

포트를 열기 전에 반환 경로를 따르라

경로에는 세 부분이 있습니다: 게이트웨이에서 클라이언트의 내부 주소를 가리키는 경로, 특정 호출자를 허용하는 정책, 그리고 대상에서 수신 대기하는 서비스입니다. 각 부분은 서로 다르게 실패하므로 «VPN이 켜져 있다»는 거의 아무것도 알려주지 않습니다.

좋은 소식은 내부 경로에 클라이언트의 가정용 라우터에서 포트 포워딩이 필요 없다는 것이며, 서비스를 가정용 WAN 주소가 아니라 터널 주소에 게시하는 이유가 바로 그것입니다. 가정용 WAN 주소에서는 노출과 NAT 규칙이 전혀 달라졌을 것입니다. 가정용 라우터는 사무실에서 오는 연결의 헤어핀을 거부할 수도 있으므로, WAN 경로는 VPN과 무관한 이유로 실패합니다. 트래픽을 터널 안에 유지하면 두 문제를 한 번에 피할 수 있습니다.

대상 쪽도 확인하십시오. 127.0.0.1에만 바인딩된 서비스는 게이트웨이 경로가 아무리 정확해도 터널 인터페이스로 도착하는 연결을 받아들일 수 없습니다. 포트를 로컬 서브넷에서만 허용하는 호스트 방화벽 규칙도 사무실 트래픽을 버리며, 그 규칙은 위의 VPN 정책과 무관합니다.

이름과 주소는 설계 결정이다

터널 안의 주소가 자동으로 이름이 되는 것은 아닙니다. 직접 통제하는 사설 DNS 레코드가 검색 프로토콜이 터널을 넘어간다고 기대하는 것보다 명확한 이유는, 링크 로컬 멀티캐스트 이름 확인이 로컬 세그먼트에 머무르고 서브넷 간 DNS가 되지 않기 때문입니다.

주소 안정성도 그만큼 중요합니다. VPN 클라이언트가 짧은 임대의 풀에서 주소를 받으면 노트북의 내부 주소가 세션 사이에 바뀌고, 그 위에 세운 모든 북마크, 방화벽 범위, 모니터링 점검이 조용히 깨집니다. 예약이나 문서화된 동적 갱신 경로를 사용하십시오.

VPN ID를 소유한 사람과 이름을 합의하여, 레코드와 주소 할당과 접근 정책이 세 개의 별도 티켓이 아니라 함께 바뀌게 하십시오.

멤버십이 아니라 서비스를 시험하라

대상에서 무엇이 어느 주소에서 수신 대기하는지 확인한 다음, 게이트웨이가 보는 반환 경로를 확인하십시오:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

이제 사무실 쪽에서 에코가 아닌 실제 요청으로 시험하십시오. 서비스에 대한 curl 성공은 경로와 정책과 수신자를 한 번에 증명하지만, 핑 성공은 ICMP가 허용된다는 것만 증명합니다. 요청이 실패하면 방화벽을 넓히고 기대하는 대신 세 부분을 거꾸로 짚어 보십시오.

가용성은 같은 대화에 속합니다. 노트북은 잠들고, 네트워크 사이를 이동하며, 하루가 끝나면 연결이 끊깁니다. 어느 시간에든 응답해야 하는 서비스는 항상 켜져 있는 호스트에 속하고, 최선 노력형 서비스는 그 한계를 적어 두고 클라이언트에 남을 수 있습니다.

이름, 허용된 호출자 목록, 소유자를 갖추어 리소스를 의도적으로 게시하면, 원격 장치는 우연한 서버가 아니라 지원되는 서비스가 됩니다.