SSH 터널링편집자 확인

로컬 포트 포워딩은 SSH 터널링의 가장 일반적인 형태로, SSH 클라이언트가 실행되는 로컬 머신의 특정 포트를 SSH 서버를 통해 원격 호스트의 포트로 전달하는 방식이다. 이는 로컬 머신에서 원격 서비스를 마치 로컬에 있는 것처럼 안전하게 접근할 수 있게 해준다.

기본적인 동작 원리는 다음과 같다. 사용자는 SSH 클라이언트에 -L 옵션을 사용하여 명령을 실행한다. 예를 들어, ssh -L 8080:target.server.com:80 user@ssh.server.com 명령은 로컬 머신의 8080번 포트로 들어오는 모든 연결을 ssh.server.com이라는 SSH 서버를 경유하여 최종적으로 target.server.com 서버의 80번 포트(HTTP 포트)로 전달한다. 이 과정에서 로컬 머신과 SSH 서버 사이의 모든 트래픽은 SSH 프로토콜에 의해 암호화된다.

주요 사용 패턴은 다음과 같다.

로컬 포트 포워딩은 SSH 서버를 신뢰할 수 있는 중계 지점으로 활용하여, 클라이언트와 최종 목적지 사이의 네트워크 구간이 보안상 취약하거나 직접 연결이 불가능한 상황에서 매우 유용하다. 터널이 설정되면 로컬 머신의 응용 프로그램은 단순히 localhost의 지정된 포트에 연결함으로써 암호화된 경로를 통해 원격 서비스와 통신할 수 있다.

원격 포트 포워딩은 SSH 터널링의 한 방식으로, SSH 서버 측의 특정 포트로 들어오는 연결을 SSH 클라이언트 측의 지정된 호스트와 포트로 전달합니다. 이는 클라이언트가 서버에게 "서버의 특정 포트를 열어서, 그곳으로 오는 모든 트래픽을 나(클라이언트)가 지정한 내부 네트워크의 목적지로 전달해 달라"고 요청하는 구조입니다. 따라서 서버를 중계점으로 활용하여, 외부에서 서버를 통해 클라이언트 측 네트워크의 서비스에 접근할 수 있게 합니다.

주요 사용 명령어 형식은 ssh -R [서버_바인딩_포트]:[목적지_호스트]:[목적지_포트] [사용자명]@[SSH_서버]입니다. 예를 들어, ssh -R 8080:localhost:3000 user@example.com 명령은 원격 서버(example.com)의 8080 포트로 들어오는 연결을, SSH 터널을 통해 클라이언트 머신의 로컬 3000 포트(localhost:3000)로 전달합니다. 목적지 호스트를 localhost가 아닌 클라이언트가 접근 가능한 다른 내부 IP(예: 192.168.1.100)로 지정하면, 해당 내부 서버로의 터널링도 가능합니다.

기본적으로 원격 포트 포워딩 시 서버는 localhost(127.0.0.1)에만 포트를 바인딩합니다. 이는 서버 자체에서만 접근 가능함을 의미합니다. 외부에서 접근하려면 SSH 서버 설정(sshd_config)에서 GatewayPorts 옵션을 yes 또는 clientspecified로 변경하고, 클라이언트에서 바인딩 주소를 명시적으로 0.0.0.0으로 지정해야 합니다(예: -R 0.0.0.0:8080:localhost:3000). 이 설정은 보안상 주의가 필요하며, 불필요한 서비스 노출을 방지하기 위해 엄격한 접근 제어와 결합되어야 합니다.

동적 포트 포워딩은 SSH 클라이언트가 SOCKS 프록시 서버 역할을 하도록 설정하는 방식이다. 로컬 포트 포워딩이나 원격 포트 포워딩이 특정 목적지 호스트와 포트를 미리 지정해야 하는 반면, 동적 포트 포워딩은 연결이 설정된 후에 클라이언트 애플리케이션의 요청에 따라 터널을 통해 임의의 목적지로 트래픽을 전달한다. 이는 사용자가 여러 다른 서비스나 사이트에 안전하게 접근해야 할 때 유용하다.

설정은 -D 옵션을 사용하여 수행된다. 예를 들어, ssh -D 1080 user@ssh-server.com 명령어는 로컬 머신의 1080번 포트에 SOCKS 프록시 서비스를 바인딩한다. 이후 웹 브라우저나 기타 SOCKS 프로토콜을 지원하는 애플리케이션의 프록시 설정을 localhost:1080(SOCKS v5)으로 지정하면, 해당 애플리케이션의 모든 네트워크 트래픽이 SSH 서버를 경유하여 암호화된 채로 외부로 전송된다. SSH 서버는 클라이언트의 요청을 받아 실제 목적지에 연결하고, 결과를 다시 클라이언트에게 안전하게 되돌려준다.

주요 사용 사례는 불안전한 공용 와이파이 네트워크에서의 웹 브라우징 보안 강화, 또는 회사 내부 방화벽을 우회하여 외부 리소스에 안전하게 접근하는 것이다. 그러나 모든 애플리케이션이 SOCKS 프록시를 지원하는 것은 아니며, 지원하더라도 DNS 조회 요청이 터널 밖으로 유출될 수 있어 주의가 필요하다. 이를 방지하려면 애플리케이션의 '원격 DNS' 또는 'SOCKS5를 통한 DNS' 옵션을 활성화하여 DNS 요청도 터널을 통해 전송되도록 설정해야 한다.

SSH 터널링은 주로 ssh 명령어에 특정 옵션을 추가하여 설정한다. 기본적인 명령어 구문은 다음과 같다.

ssh -L [로컬_바인드_주소:]로컬_포트:목적지_호스트:목적지_포트 [사용자명@]SSH_서버

ssh -R [원격_바인드_주소:]원격_포트:목적지_호스트:목적지_포트 [사용자명@]SSH_서버

ssh -D [로컬_바인드_주소:]로컬_포트 [사용자명@]SSH_서버

각 옵션의 역할은 아래와 같다.

로컬_바인드_주소나 원격_바인드_주소를 생략하면 기본적으로 127.0.0.1 (localhost)에 바인딩된다. 0.0.0.0을 지정하면 모든 네트워크 인터페이스에서 접근을 허용한다[3].

일반적인 사용 예는 다음과 같다.

• ssh -L 8080:internal.server.com:80 user@gateway.com: 로컬 머신의 8080번 포트로 접속하면, gateway.com SSH 서버를 통해 internal.server.com의 80번 포트(HTTP)로 연결된다.

• ssh -R 2222:localhost:22 user@remote.com: remote.com 서버의 2222번 포트로 접속하면, SSH 클라이언트를 실행 중인 로컬 머신의 22번 포트(SSH)로 연결된다.

• ssh -D 1080 -f -N user@proxy-server.com: 로컬 1080번 포트를 SOCKS5 프록시로 설정하고, 백그라운드에서 터널을 유지한다. 이후 웹 브라우저 등에서 이 프록시를 설정하면 모든 트래픽이 proxy-server.com을 경유하게 된다.

SSH 구성 파일을 이용하면 자주 사용하는 SSH 터널링 설정을 영구적으로 저장하고, 복잡한 명령어 옵션 대신 간단한 별칭으로 실행할 수 있다. 사용자의 홈 디렉터리 아래 .ssh/config 파일을 편집하여 설정을 관리한다. 이 파일은 일반 텍스트 형식이며, 특정 호스트나 패턴에 대한 연결 매개변수를 정의하는 데 사용된다.

터널링 설정은 Host 지시어로 시작하는 블록 안에 정의한다. 로컬 포트 포워딩은 LocalForward 옵션을 사용하며, 형식은 LocalForward [로컬_바인드_주소:]로컬_포트 원격_호스트:원격_포트이다. 예를 들어, 로컬 머신의 8080 포트를 원격 서버의 80 포트로 연결하려면 LocalForward 8080 localhost:80과 같이 작성한다. 원격 포트 포워딩은 RemoteForward 옵션으로, 동적 포트 포워딩은 DynamicForward 옵션으로 설정할 수 있다.

구성 파일을 사용할 때의 주요 장점은 재사용성과 관리의 편의성이다. 아래 표는 구성 파일에서 자주 사용되는 터널링 관련 지시어를 정리한 것이다.

설정이 완료되면, 명령줄에서 ssh mytunnel과 같이 호스트 별칭만 입력하여 모든 포워딩 설정이 적용된 연결을 즉시 시작할 수 있다. 이 방법은 특히 여러 개의 터널을 관리하거나 자동화 스크립트에 통합해야 할 때 매우 효율적이다. 구성 파일의 권한은 보안상 반드시 600 (소유자만 읽기/쓰기)으로 설정되어야 한다는 점을 주의해야 한다.

SSH 터널링의 가장 일반적인 활용 사례는 평문 통신을 사용하는 서비스의 트래픽을 암호화된 SSH 연결 안에 감추어 전송하는 것이다. 예를 들어, SMTP, POP3, IMAP과 같은 이메일 프로토콜이나 HTTP 기반의 웹 관리 인터페이스는 기본적으로 통신 내용이 암호화되지 않는다. 이러한 서비스에 직접 접근하면 네트워크 상에서 패킷이 감청될 위험이 있다. SSH 터널을 구성하면 클라이언트와 서버 간의 모든 데이터가 SSH 프로토콜의 강력한 암호화 채널을 통해 안전하게 전송된다.

구체적인 동작 방식은 주로 로컬 포트 포워딩을 사용한다. 사용자는 자신의 로컬 머신(클라이언트)에서 특정 포트를 리스닝하는 SSH 터널을 생성한다. 이 터널은 SSH 서버를 경유하여 최종 목표 서비스(예: 내부망의 웹 서버)에 연결된다. 사용자가 로컬 머신의 해당 포트에 접속하면, 연결은 자동으로 암호화된 터널을 통해 안전하게 목표 서비스로 전달된다.

이 방법은 서비스 자체를 수정하거나 TLS/SSL 인증서를 구성하는 복잡한 과정 없이, 기존 인프라를 최소한으로 변경하여 통신 보안을 즉시 강화할 수 있는 실용적인 해결책이다. 단, 이는 트래픽을 암호화하여 도청을 방지하는 전송 계층 보안에 초점을 맞춘 것이며, 서비스 자체의 인증 취약점 등을 해결해주지는 않는다는 점에 유의해야 한다.

방화벽 우회는 SSH 터널링의 가장 일반적인 사용 사례 중 하나이다. 많은 조직이나 공공 네트워크는 특정 포트나 프로토콜에 대한 접근을 차단하는 방화벽 정책을 운영한다. 예를 들어, 회사 네트워크는 업무와 무관한 원격 데스크톱 프로토콜이나 특정 메신저 서비스의 포트를 차단할 수 있다. SSH 터널링은 이러한 제한을 우회할 수 있는 안전한 통로를 제공한다. 사용자는 외부에 위치한 자신의 서버나 허용된 점프 호스트에 SSH로 연결한 후, 해당 연결을 통해 차단된 서비스로의 트래픽을 전송한다. 방화벽 입장에서는 모든 트래픽이 암호화된 SSH 연결(일반적으로 22번 포트) 하나로만 보이므로, 내부에 숨겨진 실제 통신 내용을 검사하거나 차단하기 어렵다.

제한된 네트워크 환경에서의 접근 확보 또한 중요한 용도이다. 일부 국가나 네트워크는 지리적 또는 정책적으로 특정 온라인 자원에 대한 접근을 제한할 수 있다. 연구자나 기업 직원이 해외 출장 중 현지 네트워크 제한으로 인해 내부 자료나 특정 학술 데이터베이스에 접근하지 못하는 상황이 발생할 수 있다. 이 경우, 사용자의 장비(로컬 포트 포워딩의 경우)나 중간 서버(원격 포트 포워딩의 경우)를 통해 터널을 구축하면, 마치 제한이 없는 네트워크(예: 본사 네트워크)에서 접근하는 것과 같은 효과를 얻을 수 있다. 이는 단순히 웹 접근을 넘어, 가상 사설망처럼 내부 인트라넷의 자원이나 도구에 접근하는 데 활용된다.

사용 패턴은 다음과 같이 구분된다.

이러한 우회 기술은 합법적인 목적(업무 접근, 연구)뿐만 아니라 악의적인 목적으로도 사용될 수 있으므로, 조직의 네트워크 관리자는 비정상적인 양의 SSH 트래픽을 모니터링할 필요가 있다. 또한, 터널링을 제공하는 SSH 서버 자체가 강력한 인증 방식을 갖추고 불필요한 포트 포워딩 권한을 제한하는 것이 보안상 중요하다.

SSH 터널링은 TCP/IP 기반의 애플리케이션 트래픽을 SSH의 암호화된 채널 안에 캡슐화하여 전송하는 기술이다. 이는 본질적으로 SSH 프로토콜이 제공하는 강력한 암호화와 무결성 검사 기능을 활용하여, 평문으로 통신하는 레거시 프로토콜이나 보안이 취약한 서비스의 통신을 보호한다. 터널을 통해 전달되는 모든 데이터는 대칭키 암호 방식(예: AES, ChaCha20)으로 암호화되며, 메시지 인증 코드(MAC)를 통해 변조를 탐지할 수 있다[5].

이 방식의 주요 장점은 애플리케이션 자체를 수정할 필요 없이 종단 간 암호화를 제공할 수 있다는 점이다. 예를 들어, POP3, SMTP, VNC 또는 데이터베이스 연결과 같이 기본적으로 암호화를 지원하지 않는 프로토콜을 사용할 때, 해당 트래픽을 SSH 터널 안으로 라우팅하면 네트워크 상의 스니핑이나 중간자 공격으로부터 데이터를 안전하게 보호할 수 있다. 터널의 양 끝단에서는 암호화/복호화가 투명하게 이루어지므로, 클라이언트와 서버 애플리케이션은 마치 평소처럼 로컬 포트에 연결하는 것만으로 보안 통신을 할 수 있다.

단, SSH 터널링은 애플리케이션 계층의 종단 간 암호화를 완전히 대체하지는 않는다. 터널은 주로 네트워크 구간의 보안을 담당하며, 최종 서버에 도달한 후의 데이터 처리 보안은 여전히 해당 서버의 설정에 의존한다. 또한, 암호화 오버헤드로 인한 약간의 지연이 발생할 수 있으며, 터널을 관리하는 SSH 연결 자체의 안정성이 전체 통신의 가용성을 결정한다.

SSH 터널링을 설정할 때, 바인딩 주소는 터널이 수신 대기할 네트워크 인터페이스를 지정하는 중요한 매개변수입니다. 기본적으로 SSH 클라이언트는 터널을 로컬 머신의 루프백 주소(127.0.0.1 또는 localhost)에만 바인딩합니다. 이는 동일한 시스템에서 실행 중인 응용 프로그램만 터널을 통해 연결할 수 있음을 의미하며, 외부로부터의 접근을 차단하여 보안을 강화합니다.

보다 유연한 접근이 필요한 경우, 바인딩 주소를 명시적으로 설정할 수 있습니다. 예를 들어, -L 0.0.0.0:8080:remote_host:80과 같이 0.0.0.0을 지정하면, SSH 클라이언트가 실행 중인 머신의 모든 네트워크 인터페이스에서 포트 8080으로의 연결을 수락합니다[6]. 반면, 특정 IP 주소(예: 192.168.1.100)를 지정하면 해당 인터페이스로의 접근만 허용합니다. 이 설정은 주의 깊게 사용해야 하며, 불필요하게 광범위한 주소(0.0.0.0)에 바인딩하는 것은 무단 접근의 위험을 증가시킬 수 있습니다.

바인딩 주소 설정은 SSH 구성 파일(~/.ssh/config)에서도 영구적으로 관리할 수 있습니다. 구성 파일에서는 LocalForward 지시어와 함께 bind_address를 지정합니다. 다음은 그 예시입니다.

적절한 바인딩 주소 선택은 최소 권한 원칙을 따르는 핵심 보안 조치입니다. 필요한 시스템만 터널에 접근할 수 있도록 제한함으로써, 잠재적인 공격 표면을 최소화합니다.

SSH 터널링을 구성할 때, 적절한 인증 및 접근 제어 정책을 수립하는 것은 보안상 매우 중요하다. 터널 자체가 암호화된 통로를 제공하더라도, 이 통로에 접근할 수 있는 사용자와 호스트를 제한하지 않으면 보안 위협에 노출될 수 있다.

가장 기본적인 인증 수단은 공개키 인증과 비밀번호 인증이다. 보안 강화를 위해 비밀번호보다는 공개키 인증을 사용하는 것이 권장된다[7]. 서버 측에서는 sshd_config 파일을 통해 특정 사용자나 그룹에 대한 터널링 허용 여부를 세밀하게 제어할 수 있다. 예를 들어, PermitTunnel 지시어를 사용하여 point-to-point 또는 Ethernet 터널링 허용을 설정하거나, AllowTcpForwarding 지시어로 포트 포워딩 자체를 활성화 또는 비활성화할 수 있다. 특정 포트에 대한 바인딩을 root 사용자만 가능하도록 제한하는 것도 일반적인 접근 제어 방법이다.

보다 세부적인 제어를 위해, authorized_keys 파일 내에서 각 공개키에 대한 옵션을 지정할 수 있다. 이는 특정 키로 접속한 사용자가 수행할 수 있는 작업을 제한하는 강력한 메커니즘이다. 주요 제한 옵션은 다음과 같다.

이러한 접근 제어는 최소 권한의 원칙을 적용하는 데 핵심적이다. 예를 들어, 특정 애플리케이션만을 위한 터널을 제공해야 하는 사용자에게는 완전한 셸 접근 권한 대신 permitopen 옵션으로 특정 포트로의 터널링만 허용하면, 공격 표면을 크게 줄일 수 있다. 또한, 터널의 엔드포인트(예: -L 127.0.0.1:8080:...)를 가능한 한 제한된 주소(루프백 인터페이스)에 바인딩하여, 외부 네트워크에서의 직접 접근을 차단하는 것이 좋다.

SSH 터널링 설정 및 사용 중 발생하는 일반적인 오류와 그 해결 방법은 다음과 같다.

"포트 바인딩 실패" 오류는 가장 흔히 접하는 문제 중 하나이다. 이 오류는 주로 지정한 로컬 또는 원격 포트가 이미 다른 프로세스에 의해 사용 중이거나, 권한이 없는 포트(1024 이하)를 일반 사용자가 바인딩하려 할 때 발생한다. 해결을 위해 netstat 또는 lsof 명령어로 포트 사용 여부를 확인하고, 충돌하는 서비스를 중지하거나 다른 포트를 지정한다. 권한 문제의 경우, 관리자 권한으로 실행하거나 1024번 이상의 포트를 사용하는 것이 일반적인 해결책이다.

"연결 거부됨" 또는 "타임아웃" 오류는 네트워크 연결 자체에 문제가 있음을 나타낸다. 먼저 대상 SSH 서버의 주소와 포트가 정확한지, 서비스가 실행 중인지 확인해야 한다. 방화벽이나 네트워크 정책이 SSH 연결(기본 포트 22) 또는 터널링에 사용되는 포트를 차단하고 있을 수 있다. 클라이언트와 서버 양측의 방화벽 설정을 점검하고, -v(verbose) 옵션을 사용하여 연결 과정을 상세히 출력해보면 문제 지점을 파악하는 데 도움이 된다.

터널은 성공적으로 설정되었으나 애플리케이션이 터널을 통해 연결되지 않는 경우도 있다. 이는 터널의 바인딩 주소가 기본값인 localhost(127.0.0.1)로 설정되어, 외부에서의 접근이 불가능하기 때문일 수 있다. 모든 인터페이스(0.0.0.0)에 바인딩하려면 명시적으로 -g 옵션을 사용하거나 구성 파일에서 GatewayPorts를 설정해야 한다. 또한, 애플리케이션의 프록시 또는 연결 설정이 터널의 로컬 포트를 정확히 가리키고 있는지 다시 한번 확인한다.

SSH 터널 연결 문제를 해결할 때는 시스템 로그와 SSH 클라이언트의 출력 메시지를 체계적으로 분석하는 것이 효과적이다.

클라이언트 측에서는 -v (verbose), -vv, -vvv 옵션을 사용하여 연결 과정의 상세한 디버그 정보를 확인할 수 있다. 이 로그는 인증 단계, 포트 바인딩 시도, 라우팅 문제 등을 진단하는 데 도움을 준다. 서버 측에서는 일반적으로 /var/log/auth.log (Debian 계열) 또는 /var/log/secure (RHEL 계열) 파일에서 sshd 데몬의 로그를 확인한다. 로그에는 연결 시도, 사용자 인증 성공/실패, 터널 설정 오류 등이 기록된다.

터널 연결 자체를 확인하기 위한 몇 가지 기본적인 명령어가 있다. netstat 또는 ss 명령어로 로컬 또는 원격 시스템에서 예상한 포트가 실제로 청취(listening) 상태인지, 또는 터널을 통해 연결이 확립(ESTABLISHED)되었는지 확인할 수 있다. 또한 telnet이나 nc(netcat)를 사용하여 터널의 로컬 엔드포인트에 연결을 시도함으로써 터널 경로가 정상적으로 동작하는지 간단히 테스트해볼 수 있다.

네트워크 문제가 의심될 경우, traceroute 명령으로 SSH 서버까지의 경로를 점검하거나, 방화벽 규칙이 SSH 포트(기본 22) 및 포워딩된 포트를 차단하고 있지는 않은지 확인해야 한다. 동적 포트 포워딩(SOCKS) 사용 시에는 클라이언트 애플리케이션(예: 웹 브라우저)의 프록시 설정이 올바르게 구성되었는지 다시 한번 검토한다.

autossh는 SSH 터널의 장기간 안정성을 유지하기 위해 설계된 유틸리티이다. 이 프로그램은 기본적으로 ssh 클라이언트를 감싸는 래퍼(wrapper)로 동작하며, 주기적으로 터널의 건강 상태를 확인하고 연결이 끊어지면 자동으로 재연결을 시도한다. 이는 네트워크 불안정, 게이트웨이 재시작, 장시간 유휴 상태로 인한 타임아웃 등으로 인해 SSH 터널이 예기치 않게 종료되는 문제를 해결한다. 사용자는 단일 명령어로 터널을 시작하면 되며, autossh가 백그라운드에서 연결을 지속적으로 관리한다.

autossh의 핵심 메커니즘은 모니터 포트를 이용한 연결 감시이다. autossh는 SSH 터널을 생성할 때, 데이터 전송용 포트와 별도로 모니터링용 포트를 하나 더 연다. 이 모니터링 채널을 통해 주기적으로 핑(ping)과 같은 테스트 트래픽을 보내 원격 측의 에코 서비스(echo service)로부터 응답을 확인한다. 만약 사전에 정의된 횟수만큼 연속으로 응답이 없으면, autossh는 해당 SSH 세션이 죽었다고 판단하고 프로세스를 종료한 후 새로운 SSH 연결을 다시 설정한다.

설치 후 사용법은 기존 ssh 명령어와 매우 유사하다. 가장 일반적인 형태는 -M 옵션으로 모니터 포트를 지정하고, 그 뒤에 기존의 SSH 포트 포워딩 옵션을 추가하는 것이다. 예를 들어, autossh -M 0 -L 8080:localhost:80 user@remote-server 명령은 모니터 포트를 사용하지 않는 모드(-M 0)로 로컬 8080포트를 원격 서버의 80포트로 전달하는 터널을 생성하고 관리한다. 시스템 서비스(예: systemd 유닛)로 등록하여 서버 부팅 시 자동으로 실행되게 구성하는 것이 일반적이다.

autossh는 로그를 통해 재연결 시도와 같은 중요한 이벤트를 보고하므로, 초기 설정 시 문제를 진단하는 데 도움이 된다. 이를 통해 관리자는 중요한 로컬 포트 포워딩이나 SOCKS 프록시 터널이 무중단으로 유지되도록 보장할 수 있다.

SSH 터널링은 널리 사용되는 기술이지만, 특정 요구사항에 따라 다른 터널링 기술이 더 적합할 수 있다. 각 기술은 설계 목적, 프로토콜, 성능, 구성 복잡도 측면에서 차이를 보인다.

VPN은 네트워크 계층(레이어 3)에서 동작하여 사용자 장치의 모든 네트워크 트래픽을 원격 네트워크로 라우팅한다. 이는 전체 네트워크 접근이 필요할 때 유리하지만, SSH 터널링에 비해 일반적으로 클라이언트 소프트웨어 설치와 더 복잡한 서버 구성이 필요하다. WireGuard는 최근 등장한 현대적인 VPN 프로토콜로, 코드베이스가 작고 설정이 비교적 간단하며 성능이 우수하다는 점에서 차별화된다.

stunnel은 특정 서비스(예: POP3, SMTP)의 연결만을 SSL/TLS로 암호화하는 데 특화되어 있다. 애플리케이션 자체를 수정하지 않고 보안 계층을 추가할 수 있다는 장점이 있다. ngrok이나 Cloudflare Tunnel과 같은 현대적인 터널링 서비스는 중계 서버를 통해 NAT나 방화벽 뒤에 있는 로컬 서비스를 공개 인터넷에 쉽게 노출시켜주며, 개발 및 테스트 환경에서 특히 유용하다. 이들은 사용 편의성에 초점을 맞추지만, 트래픽이 제3자의 서버를 경유한다는 점을 고려해야 한다.