공유기 뒤에 서버를 두고 외부에서 접근하려면 어떻게 해야 할까?

공유기 뒤 서버를 인터넷에 노출하는 방법 5가지와 보안 설정

공유기 뒤에 서버를 놓고 외부에서 접근하려는 순간, 처음엔 왜 안 되는지 이유도 모르고 멍하니 앉아있었던 기억이 난다. 사내 개발 서버를 외부 고객이 테스트해야 하는 상황이었는데, IP는 사설이고, 공인 IP는 공유기 한 대가 독점하고 있었다. 그때 처음 NAT와 포트 포워딩을 손으로 직접 만지면서 배웠다. 책으로 배운 개념과 실제로 공유기 설정 페이지를 열어서 규칙을 추가하는 건 전혀 다른 경험이다. 이 글은 그 경험에서 나온 이야기다.

---

NAT가 뭔지 현장에서 느낀 감각으로

NAT는 Network Address Translation, 즉 네트워크 주소 변환이다. 쉽게 말하면 공유기 하나가 공인 IP 하나를 가지고, 그 뒤에 수십 대의 내부 장비가 사설 IP로 붙어있는 구조다. 공유기가 그 경계에서 주소를 바꿔치기한다. 회사 대표 전화번호 하나로 수십 명의 직원 전화를 받아서 내선으로 연결해주는 교환원을 생각하면 된다. 외부에서는 대표 번호만 보이고, 내부 직원 번호는 보이지 않는 것처럼 말이다.

이 구조의 가장 큰 장점은 IPv4 주소 고갈 문제를 현실에서 버텨주게 해준다는 거다. IP 하나로 수백 대를 운용하는 게 가능하니까. 단점은 명확하다. 외부에서 내부로 먼저 접속을 시도하는 것이 기본적으로 막혀있다는 점이다. 내가 먼저 나가는 건 되는데, 외부에서 나를 찾아오는 건 안 된다. 서버를 운영하려면 이 장벽을 어떻게 뚫을지 방법을 찾아야 한다.

처음에 이 개념을 이해했을 때 솔직히 "이게 왜 이렇게 설계됐지?"라는 생각이 들었다. 사실 IPv4 주소 부족 문제를 임시방편으로 해결하려다 보니 생긴 구조이기도 하다. IPv6가 제대로 보급됐다면 NAT 자체가 필요 없었을 거라는 시각도 있다. 하지만 현실에서 IPv6 전환은 여전히 더디고, NAT는 보안적으로 내부 구조를 숨기는 부가 효과도 있어서 앞으로도 한동안 사라지지 않을 기술이다. 중요한 건 구조를 이해하고 활용하는 것이다.

---

방법 1: 포트 포워딩 직접 설정

가장 기본적이고 가장 많이 쓰는 방법이다. 공유기 설정 페이지에서 특정 포트로 들어오는 트래픽을 내부의 특정 서버로 연결해주는 규칙을 만드는 것이다. 호텔 프런트 데스크에서 특정 객실 번호로 전화를 연결해주는 것과 비슷한 느낌이다. "8080번 포트로 전화 오면 101호로 연결"이라는 규칙을 만드는 거라고 생각하면 된다.

iptables로 직접 구현하면 이렇다.

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.100:80
iptables -A FORWARD -p tcp -d 192.168.1.100 --dport 80 -j ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE

외부에서 공인IP:8080으로 들어오면 내부 192.168.1.100의 80포트로 넘긴다는 규칙이다. 현장에서 이 방법을 쓸 때의 장점은 제어권이 완전히 내 손 안에 있다는 것이다. 세밀하게 규칙을 만들 수 있고, 무슨 포트를 어디로 보낼지 정확히 알 수 있다.

단점은 공유기 혹은 라우터의 설정 권한이 있어야 한다는 거다. 망 관리자가 따로 있는 환경에서는 요청하고 기다려야 하고, 급하면 답답하다. 실제로 고객사 방문 일정이 이틀 후였는데 망 관리자가 출장 중이라 포트 포워딩 설정을 못 해서 발등에 불이 떨어진 적이 있었다. 그 상황에서 다른 방법을 급하게 찾았던 게 아래에 나오는 SSH 터널링이나 클라우드 터널이었다. 포트 포워딩은 확실한 방법이지만 권한 없이는 쓸 수가 없다는 게 현실적인 한계다.

---

방법 2: DMZ 설정

포트 포워딩을 하나씩 만들기 귀찮을 때, 특정 내부 서버를 향한 모든 포트를 통째로 열어버리는 방식이 DMZ다. 군사 용어 '비무장지대'에서 따왔는데, 실제로도 보안 측면에서 무방비에 가깝다. 집 대문을 활짝 열어두는 것과 같다. 편하긴 한데 위험하다.

테스트 환경이나 개발 망에서 빠르게 쓸 때는 편리하지만, 운영 서버에 DMZ 설정했다가 곤욕을 치른 케이스를 여러 번 봤다. 내가 직접 당한 건 아니지만 옆 팀 이야기가 아직도 기억난다. 불필요한 포트가 다 열려있다가 스캔을 당하고, 취약한 서비스 하나가 걸려서 한바탕 난리가 났다. DMZ는 쓰더라도 별도 보안 장비 뒤에 두거나, 이중으로 방화벽 규칙을 걸어줘야 그나마 안전하다.

솔직히 DMZ는 초보자가 가장 많이 선택하는 잘못된 방법 중 하나다. 설정이 간단하니까 유혹적으로 보이지만, 보안을 모두 포기하는 대가를 치르는 거다. 개발 환경에서만, 그리고 인터넷에 직접 연결되지 않는 내부망에서만 쓰는 게 맞다. 운영 환경에서 DMZ를 썼다가 생기는 사고는 대부분 예방 가능한 사고다. "빠르게 열고 나중에 닫아야지"라는 생각이 결국 사고로 이어지는 패턴을 여러 번 봤다.

---

방법 3: 리버스 프록시 활용

가장 즐겨 쓰는 방법이다. 내부 서버를 직접 외부에 노출하지 않고, 외부에 프록시 서버 하나를 두고 그쪽으로만 트래픽을 받는다. 프록시가 내부로 중계한다. 경비원을 두는 방식이랄까. 외부 손님은 경비원만 만나고, 내부 직원들은 경비원이 연결해주는 것만 받는다.

Nginx를 리버스 프록시로 쓰는 기본 설정이다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://192.168.1.100:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

장점은 내부 구조를 숨길 수 있고, SSL 종단을 프록시에서 처리할 수 있으며, 로드밸런싱도 얹을 수 있다는 거다. 단점은 프록시 서버 자체가 장애 포인트가 된다는 것이다. 프록시가 죽으면 다 죽는다. 이중화를 같이 고려해야 제대로 된 구성이 된다.

처음 리버스 프록시를 도입했을 때는 설정 파일 작성이 낯설어서 고생했다. proxy_set_header 설정을 빠뜨려서 애플리케이션이 클라이언트 IP를 항상 프록시 IP로 인식하는 문제가 생겼던 일도 있다. 사용자 로그가 전부 같은 IP로 찍혀서 분석이 안 됐다. X-Real-IP 헤더를 설정에 추가하고 나서야 해결됐다. 이런 세부 설정들을 빠뜨리면 나중에 이상한 문제가 생기니까, 처음에 기본 설정을 꼼꼼히 챙기는 게 중요하다.

---

방법 4: SSH 터널링

임시로 빠르게 뚫어야 할 때 쓰는 방법이다. 별도 설정 없이 SSH 하나만 열려있으면 내부 서비스를 외부에서 접근할 수 있게 만들 수 있다. 배관 속에 또 다른 배관을 넣는 느낌이다. 기존 SSH 채널 위에 다른 트래픽을 얹어서 보내는 거다.

ssh -R 8080:localhost:3000 user@외부서버IP

이 명령을 내부 서버에서 실행하면, 외부 서버의 8080 포트로 들어오는 트래픽이 내부 서버의 3000으로 연결된다. 포트 포워딩 권한이 없을 때 정말 유용하다. 개발 중인 기능을 고객에게 급하게 보여줘야 할 때 이 방법으로 5분 안에 해결한 적이 여러 번 있다.

장점은 빠르고 추가 인프라가 필요 없다는 거다. 단점은 임시방편이라 안정성이 없고, SSH 연결이 끊기면 같이 죽는다. 운영 환경에 쓰면 안 된다. 개발자 도구로만 써야 한다.

SSH 터널링은 편리하지만 보안 관점에서 한 가지 주의할 점이 있다. 외부 서버의 GatewayPorts 설정이 yes로 되어 있어야 원격에서 접근이 가능한데, 이 설정은 서버의 모든 인터페이스에서 해당 포트를 열어버리는 것이다. 테스트용 서버라도 방화벽으로 접근 가능한 IP를 제한해두는 게 좋다. "임시니까 괜찮겠지"라는 생각이 가장 위험한 생각이다.

---

방법 5: 클라우드 터널 서비스 활용

요즘은 이 방법이 많이 쓰인다. ngrok 같은 서비스나 Cloudflare Tunnel 같은 도구가 그것이다. 내부 네트워크에서 외부 서비스로 연결을 먼저 맺어두고, 외부 트래픽을 그 연결을 통해 내부로 역으로 흘려보내는 방식이다. 내가 먼저 손을 내밀면 상대방이 그 손을 잡고 들어오는 구조다.

cloudflared tunnel --url http://localhost:3000

이것만 치면 외부에서 접근 가능한 URL이 생긴다. 공유기 설정도 필요 없고, 공인 IP도 필요 없다. 사무실 어디서든 인터넷만 되면 된다. 설정이 극단적으로 간단하고, 공유기 설정 권한이 없어도 된다.

단점은 외부 서비스에 의존한다는 거다. 해당 서비스가 정책을 바꾸거나 장애가 나면 내 서비스도 영향을 받는다. 그리고 내 트래픽이 외부 서버를 경유한다는 게 보안상 신경 쓰인다. 민감한 데이터라면 이 방법은 피하는 게 맞다.

클라우드 터널 서비스를 처음 써봤을 때 솔직히 마법 같다는 느낌이 들었다. 명령어 하나에 URL이 생기는 게 신기했다. 하지만 내 트래픽이 제3의 회사 서버를 통과한다는 사실은 항상 머릿속에 있어야 한다. 개인 프로젝트나 공개 데모용이라면 큰 문제가 없지만, 고객 데이터나 인증 정보가 오가는 서비스라면 이용 약관과 데이터 처리 방식을 반드시 확인해야 한다. 편리함 뒤에 숨어있는 대가를 알고 써야 한다.

---

보안 설정 빠뜨리면 낭패

어떤 방법을 쓰든 방화벽 규칙은 기본이다. 필요한 포트만 열고, 나머지는 전부 막는 것이 원칙이다. 포트를 열었으면 접근 가능한 IP 대역도 제한하는 게 좋다. 전 세계 누구나 접근 가능한 서비스를 만드는 게 목적이 아니라면 말이다.

iptables -A INPUT -p tcp --dport 22 -s 1.2.3.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

SSH를 특정 대역에서만 허용하는 예시다. fail2ban 같은 도구를 추가로 달아서 무차별 대입 공격을 자동으로 차단하는 것도 현장에서는 기본으로 깔고 간다.

보안 설정을 나중에 해야지라고 미루는 사람들을 많이 봤다. 서버를 열면서 "일단 되게 만들고 나서 보안 챙기자"라는 생각은 정말 위험하다. 실제로 아무 보호 없이 공인 IP에 SSH 포트를 열어두면 몇 분도 안 돼서 로그에 수천 건의 접속 시도가 찍힌다. 세상에는 자동화 봇이 항상 스캔하고 있다. 포트를 여는 순간부터 보안을 함께 챙기는 습관이 중요하다. 방화벽 규칙 추가하는 데 1분도 안 걸리는데, 그게 뚫리면 수습하는 데 며칠이 걸린다.

---

마무리 생각

NAT와 포트 포워딩은 네트워크를 다루는 사람이라면 피할 수 없는 주제다. 처음엔 그냥 공유기 설정 페이지에서 버튼 몇 개 누르는 작업처럼 보였다. 근데 이게 쌓이다 보면 네트워크 패킷이 어떻게 흐르는지, 경계에서 무슨 일이 일어나는지 감이 잡히기 시작한다. 그 감이 잡히는 순간부터 장애 대응 속도가 달라진다. 다섯 가지 방법을 다 써본 경험이 있고, 상황마다 쓰는 게 다르다. 정답은 없고, 맥락에 맞는 선택이 있을 뿐이다. 현장은 그걸 가르쳐준다.

---

출처 및 참고 링크

• RFC 3022 - Traditional IP Network Address Translator: https://www.rfc-editor.org/rfc/rfc3022
• iptables 매뉴얼: https://linux.die.net/man/8/iptables
• nftables 위키: https://wiki.nftables.org/