13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 방화벽 설정

  • [홈랩] MikroTik 라우터 1년 사용 후기와 보안 설정 팁

    [홈랩] MikroTik 라우터 1년 사용 후기와 보안 설정 팁

    [홈랩] MikroTik 라우터 1년 사용 후기와 보안 설정 팁

    홈랩을 굴리다 보면 결국 네트워크가 제일 먼저 발목을 잡습니다. 서버는 잘 뜨는데 외부 접속이 불안정하고, 포트 하나 열었다가 괜히 마음이 찝찝하고, 가족이 같이 쓰는 인터넷까지 느려지면 그때부터는 진짜 골치 아프거든요. 저도 그런 흐름을 몇 번 겪고 나서 MikroTik 라우터 홈랩 구성을 1년 정도 꾸준히 써봤습니다. 결론부터 말하면, 초반 진입장벽은 좀 있지만 네트워크 보안과 세밀한 제어에서는 꽤 만족도가 높았어요.

    특히 MikroTik은 겉으로 보기엔 투박한데, 실제로 써보니까 라우터 설정 자유도가 높아서 홈랩처럼 실험이 많은 환경에 잘 맞더라고요. 반대로 말하면, 기본값만 믿고 쓰면 안 되는 부분도 분명히 있습니다. 저도 처음엔 이게 뭔가 싶었는데, Input(인풋, 라우터 자신으로 들어오는 트래픽) 체인과 Forward(포워드, 내부 네트워크를 통과하는 트래픽) 체인 개념을 제대로 안 잡고 시작했다가 삽질 좀 했습니다 ㅎㅎ

    이번 글에서는 제가 1년 동안 MikroTik 라우터를 홈랩에서 굴리면서 느낀 점, 실제로 적용해 둔 보안 중심 설정, 그리고 자주 겪는 문제 해결 팁까지 한 번에 정리해보겠습니다.

    홈랩 네트워크에서 MikroTik 라우터가 인터넷, 내부 VLAN, 관리망 사이를 어떻게 중재하는지 보여주는 개요 이미지입니다.

    MikroTik 라우터를 홈랩에 쓰면 좋은 이유

    쉽게 말해 MikroTik의 장점은 세밀함입니다. 일반 가정용 공유기는 메뉴가 친절한 대신 할 수 있는 일이 제한적이죠. 반면 MikroTik은 방화벽 규칙, NAT(Network Address Translation, 네트워크 주소 변환), VLAN(Virtual LAN, 가상 랜), Queue(대역폭 제어) 같은 기능을 꽤 촘촘하게 만질 수 있어요.

    • 방화벽 정책을 세분화하기 좋습니다.
    • 홈랩 서버용 네트워크와 가족용 네트워크 분리가 수월합니다.
    • 문제 원인 추적이 비교적 명확합니다.
    • CLI(Command Line Interface, 명령줄 환경)와 GUI 둘 다 쓸 수 있어 관리 방식 선택 폭이 넓습니다.

    제가 직접 해보니 가장 큰 차이는 “열어둔 만큼만 열린다”는 느낌이었습니다. 다른 장비에서는 마법사 기반 설정이 편한 대신 내부 동작이 불투명할 때가 있었는데, MikroTik은 규칙을 내가 만들고 내가 읽을 수 있어서 나중에 점검하기가 편했어요. 홈랩에서는 이게 생각보다 큽니다.

    1년 써보며 정리한 핵심 개념

    여기서 중요한 포인트! MikroTik을 잘 쓰려면 메뉴보다 트래픽 흐름을 먼저 이해해야 합니다.

    1. Input과 Forward를 구분해야 합니다

    이걸 헷갈리면 방화벽을 만든다고 만들었는데 정작 라우터 관리 포트는 열려 있고, 내부 서버는 막혀 있는 이상한 상태가 생깁니다.

    • Input: 라우터 자신에게 들어오는 접속입니다. 예를 들면 WinBox, SSH, DNS 요청 같은 것들입니다.
    • Forward: PC에서 서버로, VLAN에서 인터넷으로 흐르는 통과 트래픽입니다.
    • Output: 라우터가 바깥으로 내보내는 트래픽입니다.

    저도 처음엔 외부 관리 포트를 막는다고 생각하고 Forward 쪽만 만졌었는데, 실제로는 Input을 정리해야 하더라고요. 이거 한 번 헷갈리면 “분명 막았는데 왜 접속되지?”가 반복됩니다.

    2. 기본 허용보다 기본 거부가 편합니다

    홈랩은 서비스가 계속 늘어납니다. NAS 하나 추가하고, 리버스 프록시(Reverse Proxy, 요청을 대신 받아 전달하는 프록시) 붙이고, 테스트용 VM도 늘어나죠. 이런 환경에서는 기본 거부(Default Deny, 기본적으로 막고 필요한 것만 허용)가 훨씬 관리하기 쉬워요.

    3. 관리망을 분리하면 마음이 편합니다

    MikroTik 라우터 홈랩 구성을 오래 유지하려면 관리용 단말과 실험용 서버를 같은 네트워크에 두지 않는 게 좋습니다. 저는 최소한 아래 3개는 분리하는 쪽이 낫다고 봐요.

    1. 관리망: 라우터, 스위치, 하이퍼바이저 관리 페이지
    2. 서버망: NAS, VM, 컨테이너 호스트
    3. 일반 사용자망: 노트북, TV, 모바일 기기

    제가 실제로 잡아둔 홈랩 네트워크 보안 기준

    1년 운영하면서 결국 아래 원칙으로 정리됐어요. 완벽한 정답은 아니지만, 가정용과 홈랩 사이 균형은 괜찮았습니다.

    항목 처음 구성 1년 사용 후 정착한 방식
    관리 접속 어디서나 접속 가능 관리망 또는 허용 IP만 접속
    포트 오픈 서비스별 직접 오픈 필수 포트만 오픈, 가능하면 VPN 우선
    내부 분리 단일 LAN 관리망/서버망/사용자망 분리
    로그 확인 문제 생기면 그때 확인 방화벽 드롭 로그를 주기적으로 점검
    DNS 사용 혼합 사용 내부 클라이언트 경로를 명확히 통일

    특히 외부 공개 서비스는 생각보다 적게 가져가는 게 좋습니다. 홈랩 하다 보면 이것도 열고 싶고 저것도 열고 싶거든요. 근데 실제로 운영해보면 외부 Ingress(인그레스, 외부 트래픽 진입점)는 줄일수록 편해요. 저는 나중에 대부분 VPN 뒤로 넣는 방향으로 바꿨습니다.

    MikroTik 라우터 설정 팁: 처음 세팅할 때 꼭 하는 것

    아래는 제가 새 장비를 잡으면 거의 공통으로 보는 항목입니다. 인터페이스 이름은 환경마다 다르니 그대로 복붙하기보다 구조를 보고 적용하시면 됩니다.

    1. 관리 접속 가능 대역을 먼저 정합니다.
    2. Input 체인에서 불필요한 관리 포트를 막습니다.
    3. Established/Related(이미 수립되었거나 연관된 연결)를 먼저 허용합니다.
    4. Invalid(비정상 상태 연결)를 초반에 드롭합니다.
    5. Forward 체인에서 VLAN 간 접근 범위를 최소화합니다.
    6. NAT와 포트 포워딩은 마지막에 추가합니다.

    예시 1. 관리용 주소 목록 만들기

    /ip firewall address-list
    add list=mgmt-allow address=192.168.10.0/24 comment="management subnet"
    add list=mgmt-allow address=192.168.20.50 comment="admin laptop"
    

    이렇게 Address List(주소 목록)를 먼저 만들어 두면 규칙 읽기가 훨씬 편해요. 나중에 IP가 바뀌어도 룰 전체를 고칠 필요가 없거든요.

    예시 2. Input 체인 기본 보안

    /ip firewall filter
    add chain=input action=accept connection-state=established,related comment="allow established,related"
    add chain=input action=drop connection-state=invalid comment="drop invalid"
    add chain=input action=accept src-address-list=mgmt-allow comment="allow management"
    add chain=input action=accept protocol=icmp comment="allow icmp"
    add chain=input action=drop in-interface=ether1 comment="drop direct WAN access to router"
    

    여기서 핵심은 라우터 자신에 대한 접근을 최소화하는 겁니다. 저는 초반에 WinBox 포트만 생각했는데, 실제로는 Input 전체를 보는 게 맞더라고요.

    MikroTik 라우터 설정과 VLAN 분리, 방화벽 규칙을 설명하는 홈랩 이미지

    주소 목록, Input 규칙, VLAN 분리 흐름을 한눈에 이해할 수 있도록 구성한 설정 개념 이미지입니다.

    예시 3. Forward 체인 최소 허용

    /ip firewall filter
    add chain=forward action=accept connection-state=established,related comment="allow established,related"
    add chain=forward action=drop connection-state=invalid comment="drop invalid"
    add chain=forward action=accept src-address=192.168.30.0/24 dst-address=192.168.50.10 protocol=tcp dst-port=443 comment="allow reverse proxy to app"
    add chain=forward action=drop src-address=192.168.30.0/24 dst-address=192.168.10.0/24 comment="block user net to management net"
    

    이런 식으로 필요한 통신만 열어두면 나중에 서버가 늘어나도 기준이 안 흔들려요. 처음엔 답답해 보여도, 실서비스 비슷하게 운영하려면 이 방식이 결국 편합니다.

    예시 4. 포트 포워딩은 짧고 명확하게

    /ip firewall nat
    add chain=dstnat action=dst-nat protocol=tcp in-interface=ether1 dst-port=443 to-addresses=192.168.50.10 to-ports=443 comment="https to reverse proxy"
    

    포트 포워딩은 간단해 보여도 공격 표면이 바로 늘어나는 지점이에요. 그래서 저는 메모를 꼭 남깁니다. 나중에 “이 규칙 왜 열었지?”가 생각보다 자주 옵니다.

    ⚠️ 1년 동안 실제로 겪은 문제와 해결법

    좋은 얘기만 하면 재미없죠. 실제 운영에서는 꼭 한 번씩 걸리는 포인트가 있어요.

    문제 1. 룰 순서 때문에 허용한 줄 알았는데 계속 차단됨

    MikroTik 방화벽은 위에서 아래로 평가됩니다. 이걸 머리로는 아는데, 작업하다 보면 은근히 놓칩니다. 저도 특정 VLAN에서 NAS 접근을 열어뒀다고 생각했는데, 앞단의 Drop 규칙이 먼저 맞아서 안 되더라고요.

    • 증상: 규칙은 있어 보이는데 트래픽이 통과하지 않음
    • 원인: 더 앞쪽에 포괄적인 Drop 규칙 존재
    • 해결: 허용 규칙을 상단으로 올리고 로그로 재확인

    문제 2. FastTrack 때문에 트래픽 추적이 헷갈림

    성능 최적화용 FastTrack(패스트트랙, 일부 연결을 빠르게 처리하는 기능)은 분명 유용한데, 트러블슈팅할 때는 흐름이 덜 보일 수 있어요. 특히 로그나 세밀한 정책 테스트 중에는 “왜 예상대로 안 보이지?” 싶은 순간이 있습니다.

    저는 정책 검증 단계에서는 단순하게 가는 편이 낫다고 느껴요. 성능이 급한 게 아니라면 먼저 정책을 안정화하고, 그 다음 최적화를 보는 순서가 덜 헷갈립니다.

    문제 3. DNS 경로가 섞여서 내부 접근이 이상해짐

    이건 진짜 많이 겪어요. 일부 장비는 라우터 DNS를 보고, 일부는 외부 DNS를 보고, 내부 도메인은 또 다른 서버를 보면 결과가 제각각이거든요.

    • 증상: 같은 주소인데 PC와 모바일 결과가 다름
    • 원인: DNS 경로 혼재
    • 해결: DHCP에서 기본 DNS 경로를 통일하고, 내부 레코드는 일관된 서버로 처리

    문제 4. 원격 관리 열어두고 마음이 불편해짐

    사실 이건 기술 문제보다 운영 습관 문제에 가까워요. 외부에서 바로 관리 페이지 접속 가능하게 두면 편하긴 한데, 시간이 갈수록 찜찜해요. 저도 한동안은 편의성 때문에 열어뒀다가 결국 VPN 뒤로 옮겼습니다. 그 후로는 심리적으로도 훨씬 편하더라고요.

    검증은 이렇게 했습니다

    설정은 했는데 정말 적용됐는지 확인하는 과정이 중요해요. 라우터 설정은 “저장했다”가 끝이 아니거든요.

    1. 관리망 단말에서만 라우터 관리 포트 접속이 되는지 확인합니다.
    2. 사용자망에서 관리망으로 접근이 차단되는지 테스트합니다.
    3. 외부 공개 포트가 필요한 것만 열려 있는지 스캔합니다.
    4. 로그에서 반복 드롭 이벤트가 있는지 확인합니다.
    5. 장애 시 우회 경로가 없는지 다시 봅니다.
    # 내부 클라이언트에서 경로 확인 예시
    ping 192.168.10.1
    traceroute 192.168.50.10
    
    # 외부 노출 포트 확인 예시
    nmap -Pn example.com
    

    실제로 써보니까 검증은 한 번으로 안 끝나더라고요. 장비 하나 추가할 때마다 정책이 흔들릴 수 있어서, 저는 변경 후 간단 체크리스트를 매번 돌립니다. 이런 습관이 나중에 큰 사고를 줄여주더라고요.

    MikroTik 라우터 홈랩 검증 단계의 방화벽 로그와 네트워크 보안 점검 이미지

    설정 적용 후 방화벽 드롭 로그와 포트 노출 상태를 점검하는 검증 단계의 분위기를 보여주는 이미지입니다.

    1년 사용 후기: 좋았던 점과 아쉬웠던 점

    좋았던 점

    • 정책이 눈에 보여요. 방화벽과 NAT가 명시적이라 운영 판단이 편합니다.
    • 홈랩 확장성이 좋아요. VLAN, 서버망 분리, 테스트망 추가가 자연스럽습니다.
    • 문제 원인을 추적하기 좋습니다. 조금만 익숙해지면 “어느 체인에서 막히는지” 보이기 시작해요.

    아쉬웠던 점

    • 초기 진입장벽이 있어요. 처음엔 메뉴보다 개념이 먼저라서 낯섭니다.
    • 대충 설정하면 오히려 더 헷갈립니다. 규칙 이름, 주소 목록 정리를 안 하면 시간이 갈수록 복잡해져요.
    • 편의 기능보다 원리 이해가 필요해요. 이게 장점이자 단점이더라고요.

    그래도 1년 지나고 보니 저는 만족 쪽입니다. 특히 MikroTik 라우터 홈랩 환경에서는 “작게 시작해서 점점 정교하게 만든다”는 흐름이 잘 맞았어요. 처음엔 어렵지만, 어느 순간부터는 네트워크가 덜 무섭습니다. 이 느낌이 꽤 큽니다.

    처음 시작하는 분께 드리는 설정 순서 추천

    혹시 지금 막 MikroTik으로 넘어오려는 분이라면, 처음부터 모든 기능을 다 만지지 마세요. 저도 욕심내서 한 번에 VLAN, VPN, QoS, 포트포워딩 다 넣었다가 스스로 길을 잃었어요.

    1. 기본 인터넷 연결부터 안정화합니다.
    2. 관리 접속 제한을 먼저 적용합니다.
    3. 내부 네트워크 분리는 2~3개 대역부터 시작합니다.
    4. 외부 공개 서비스는 최소화합니다.
    5. 로그와 주석(comment)을 남깁니다.
    6. 원격 관리는 VPN 우선으로 가져갑니다.

    💡 팁 하나 더 드리면, 규칙 이름을 사람이 읽을 수 있게 적어두세요. 나중에 몇 달 지나서 보면 기억 안 난답니다. 이건 진짜예요.

    자주 묻는 질문 정리

    Q1. 홈랩에서 MikroTik은 초보자에게 너무 어렵지 않나요?

    처음엔 어려워요. 다만 단순히 불친절해서라기보다, 네트워크 원리를 드러내기 때문입니다. 대신 한 번 구조를 익히면 다른 장비를 봐도 이해가 빨라집니다.

    Q2. 포트포워딩보다 VPN이 더 나은가요?

    대부분의 관리 접속은 그래요. 외부에서 꼭 공개해야 하는 서비스가 아니라면 VPN 뒤로 숨기는 편이 보안상 낫고 운영도 편합니다.

    Q3. 꼭 VLAN까지 해야 하나요?

    처음부터는 아니에요. 하지만 홈랩 서버가 늘어나고 IoT 기기가 섞이면 분리의 효과가 확실히 보여요. 최소한 관리망과 일반망 분리는 추천드립니다.

    마무리: 1년 써보니 결국 남는 건 구조였습니다

    이번 MikroTik 라우터 홈랩 1년 사용 후기를 한 줄로 줄이면 이렇습니다. “화려한 기능보다 구조를 이해하게 만드는 장비”였어요. 처음엔 낯설고, 룰 하나 잘못 넣으면 식은땀이 나기도 해요. 근데 그 과정을 지나고 나면 네트워크 보안 관점이 달라집니다. 저도 처음엔 그냥 인터넷만 되면 된다고 생각했었는데, 지금은 트래픽이 어디서 들어오고 어디로 나가는지부터 보게 되더라고요.

    특히 네트워크 보안과 라우터 설정을 장기적으로 관리해야 하는 홈랩이라면, MikroTik은 꽤 괜찮은 선택지였어요. 다만 처음부터 크게 벌이지 말고, 관리 접속 제한과 네트워크 분리부터 차근차근 가시는 걸 추천드립니다.

    다음 글에서는 홈랩에서 VPN 중심 원격 접속 구조를 어떻게 잡는지, 그리고 리버스 프록시 앞단을 어떻게 단순하게 유지하는지 이어서 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈 서버 백업 전략과도 연결되는 내용이라 같이 보시면 흐름이 더 잘 잡히실 겁니다.

    초기 단일망 구성과 현재 분리된 홈랩 구성을 비교하며, 보안과 운영 편의성이 어떻게 달라졌는지 요약한 이미지입니다.

    🎉 한 번에 완벽하게 만들 필요는 없어요. 중요한 건, 내가 왜 이 규칙을 넣었는지 설명할 수 있는 상태로 운영하는 겁니다. 그게 결국 오래 가더라고요.

  • [Linux] 리눅스 네트워크 설정 실패 회고: 1년 운영 경험으로 배운 베스트 프랙티스

    [Linux] 리눅스 네트워크 설정 실패 회고: 1년 운영 경험으로 배운 베스트 프랙티스

    리눅스 네트워크 설정 실패 회고: 1년 운영 경험으로 배운 베스트 프랙티스

    리눅스 서버를 1년 정도 꾸준히 운영하다 보면, 결국 한 번쯤은 리눅스 네트워크 설정 실패를 겪게 되더라고요. 저도 홈랩에서 Ubuntu Server, Rocky Linux 계열, Debian 계열을 번갈아 굴리면서 꽤 여러 번 삽질했습니다 ㅎㅎ 특히 원격으로 붙어 있는 서버에서 네트워크를 잘못 건드리면, 그 순간 SSH가 끊기고 화면 앞에서 멍해지는 경험을 하게 됩니다. 이 글은 그런 실수들을 그냥 흑역사로 남기지 않고, 리눅스 서버 운영 관점에서 무엇을 조심해야 하는지 정리한 회고입니다.

    이번 글에서는 제가 실제로 자주 부딪혔던 iptables(아이피테이블즈, 리눅스 패킷 필터/방화벽) 실수, DNS(Domain Name System) 설정 꼬임, netplan(넷플랜, Ubuntu 계열 네트워크 설정 도구) 문제를 중심으로 풀어보겠습니다. 화려한 이론보다, 운영하면서 왜 망가졌는지와 어떻게 복구했는지가 더 중요하거든요.

    리눅스 네트워크 설정 실패를 설명하는 홈랩 서버 네트워크 구성 이미지

    홈랩에서 라우터, 스위치, 리눅스 서버, 관리용 노트북이 연결된 전체 네트워크 개요를 보여주는 이미지입니다.

    1. 왜 리눅스 네트워크 설정 실패가 운영에서 치명적인가

    서버에서 네트워크는 그냥 연결만 되면 끝나는 영역처럼 보이는데, 실제로는 아닙니다. 서비스 장애의 시작점이 되는 경우가 많습니다. CPU나 메모리는 눈에 보이게 올라가지만, 네트워크는 조용히 잘못되는 경우가 많거든요.

    • SSH는 되는데 외부 패키지 저장소 접근이 안 되는 경우
    • IP는 붙었는데 DNS 조회가 안 돼서 애플리케이션이 죽는 경우
    • 방화벽 규칙이 꼬여서 특정 포트만 막히는 경우
    • 재부팅 후 설정이 다르게 올라오는 경우

    여기서 중요한 포인트! 리눅스 네트워크 설정 실패는 대부분 한 번에 크게 터지지 않습니다. 처음엔 “어? 왜 이렇게 느리지?” 정도로 시작하다가, 나중엔 서비스가 안 뜨는 식으로 번지더라고요. 저도 처음엔 이게 뭔가 싶었는데, 결국 원인은 기본값을 너무 믿었던 데 있었습니다.

    2. 쉽게 말해 보는 핵심 개념: IP, Gateway, DNS, Firewall

    복잡해 보여도 네트워크는 몇 가지만 분리해서 보면 정리가 됩니다. 쉽게 말해, 서버가 네트워크에서 길을 찾고, 이름을 해석하고, 누굴 통과시킬지 결정하는 과정입니다.

    구성 요소 역할 리눅스 네트워크 설정 실패 증상
    IP Address 서버 자신의 주소 같은 대역 충돌, 접속 불가
    Gateway 다른 네트워크로 나가는 출구 외부 통신 실패
    DNS 이름을 IP로 바꾸는 해석기 도메인 접근 실패, 업데이트 실패
    Firewall 들어오고 나가는 트래픽 제어 특정 포트만 차단, 간헐적 장애

    운영 입장에서 보면 순서도 중요합니다. 보통은 링크(Link, 물리/가상 NIC 상태)가 살아 있는지 확인하고, 그다음 IP, 라우팅, DNS, 방화벽 순으로 봐야 합니다. 근데 저도 예전에는 바로 iptables부터 의심했었거든요. 실제로는 게이트웨이 한 줄이 빠진 경우가 더 많았습니다.

    3. 1년 운영하면서 가장 많이 했던 리눅스 네트워크 설정 실패 세 가지

    3-1. iptables 실수: 기본 정책부터 DROP으로 바꿨다가 SSH 차단

    iptables 실수는 진짜 한 번은 꼭 겪습니다. 저도 “보안을 좀 더 깔끔하게 하자”는 생각으로 INPUT 기본 정책을 DROP으로 바꿨다가, SSH 허용 규칙 적용 순서를 잘못 넣어서 바로 접속이 끊긴 적이 있습니다. 콘솔이 붙어 있어서 망정이지, 원격 장비였으면 더 골치 아팠을 겁니다.

    3-2. DNS 설정 꼬임: ping은 되는데 apt와 curl이 실패

    이건 초보 때보다 오히려 익숙해진 뒤에 더 자주 터지더라고요. IP 통신은 되는데 저장소 접근이 안 되면 대개 DNS 설정 문제였습니다. 특히 systemd-resolved를 쓰는 환경에서 /etc/resolv.conf를 직접 고쳐 버리면, 재부팅이나 네트워크 재시작 때 다시 꼬이는 경우가 있었습니다.

    3-3. netplan 문제: YAML 들여쓰기 하나로 네트워크가 안 올라옴

    netplan 문제는 문법 자체는 단순한데, YAML이 공백에 민감해서 생각보다 자주 발목을 잡습니다. 제가 직접 해보니, 설정을 급하게 바꾸다가 NIC 이름을 잘못 쓰거나 들여쓰기를 틀리면 부팅 후 네트워크가 예상과 다르게 올라오더라고요. 특히 ens18과 eth0를 혼동하는 케이스가 많았습니다.

    4. 실전 구현: 안전하게 네트워크 설정 바꾸는 절차

    여기서는 제가 지금도 지키는 최소한의 변경 절차를 정리해보겠습니다. 핵심은 한 번에 바꾸지 않고, 검증 가능한 작은 단위로 진행하는 겁니다.

    1. 현재 상태를 백업합니다.
    2. 활성 NIC 이름과 라우팅 테이블을 확인합니다.
    3. IP, Gateway, DNS를 한 번에 다 바꾸지 말고 순서대로 적용합니다.
    4. 원격 작업이면 세션을 하나 더 열어 둡니다.
    5. 방화벽은 허용 규칙을 먼저 넣고 기본 정책을 나중에 바꿉니다.
    6. 적용 후 즉시 ping, ss, resolvectl, journalctl로 검증합니다.
    ip -brief address
    ip route
    resolvectl status
    ss -tulpen
    sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak
    sudo iptables-save > ~/iptables-backup.rules

    이 정도만 해도 복구 속도가 확실히 빨라집니다. 저는 예전엔 백업 없이 바로 수정했었는데, 그게 제일 큰 실수였습니다.

    4-1. netplan 예시

    network:
      version: 2
      renderer: networkd
      ethernets:
        ens18:
          dhcp4: false
          addresses:
            - 192.168.0.50/24
          routes:
            - to: default
              via: 192.168.0.1
          nameservers:
            addresses:
              - 1.1.1.1
              - 8.8.8.8

    적용 전에 꼭 문법을 다시 보셔야 합니다. 원격 서버라면 특히 더요.

    sudo netplan generate
    sudo netplan try

    netplan try는 정말 유용합니다. 잘못 적용하면 자동으로 이전 상태로 되돌릴 수 있어서, 저처럼 리눅스 네트워크 설정 실패를 많이 겪은 사람에게는 안전벨트 같은 기능이거든요.

    리눅스 네트워크 설정 실패 대응을 위한 netplan 설정 검증 이미지

    netplan YAML 파일과 터미널에서 ip, route, resolvectl로 확인하는 과정을 함께 보여주는 이미지입니다.

    4-2. iptables 적용 예시

    sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
    sudo iptables -A INPUT -i lo -j ACCEPT
    sudo iptables -P INPUT DROP
    sudo iptables -P FORWARD DROP
    sudo iptables -P OUTPUT ACCEPT

    여기서 순서가 중요합니다. 허용 규칙을 먼저 넣고 마지막에 정책을 조정해야 합니다. 저는 예전에 이 순서를 반대로 했다가 SSH가 끊겼습니다. iptables 실수의 전형적인 사례죠. “드디어 됐다!” 싶어서 정책부터 바꾸면, 바로 사고 납니다.

    4-3. DNS 점검 예시

    ping -c 2 8.8.8.8
    getent hosts example.com
    resolvectl query example.com
    cat /etc/resolv.conf

    IP로는 통신되는데 도메인만 안 되면 DNS 설정을 보시면 됩니다. 반대로 DNS 설정이 정상인데도 외부가 안 되면 라우팅이나 방화벽 쪽일 가능성이 높습니다.

    5. ⚠️ 실제 리눅스 네트워크 설정 실패 사례와 복구 과정

    이 섹션은 좀 더 현실적인 회고입니다. 보기엔 사소한데, 운영에선 꽤 아픈 문제들이었습니다.

    5-1. 게이트웨이 누락으로 내부망만 되고 외부망은 불가

    서버 간 통신은 되는데 패키지 업데이트가 안 됐습니다. 처음엔 DNS 문제인 줄 알았는데, 실제로 써보니까 기본 게이트웨이(default gateway)가 빠져 있더라고요. 내부망은 같은 서브넷이라 통신되지만, 외부로 나갈 출구가 없으니 당연히 실패한 겁니다.

    • ip route에 default 경로가 있는지 확인
    • 게이트웨이 IP가 실제 라우터 주소와 일치하는지 확인
    • 정적 라우트가 있으면 우선순위도 함께 점검

    5-2. NIC 이름 오인으로 netplan 적용 실패

    가상화 환경을 옮기고 나서 기존 설정을 그대로 썼는데 NIC 이름이 달랐습니다. 예전엔 eth0였는데 새 환경에서는 ens18로 올라왔거든요. 문법은 맞는데 적용이 안 되니 한참 헤맸습니다. 이것도 리눅스 네트워크 설정 실패의 전형적인 경우죠.

    • ip -brief link로 실제 인터페이스 이름 확인
    • 클라우드 이미지나 VM 템플릿 복제 시 이름이 바뀔 수 있음
    • 문법보다 장치 식별이 먼저라는 점을 기억

    5-3. 방화벽 저장 누락으로 재부팅 후 규칙 유실

    이것도 흔합니다. 세션 중에는 잘 되는데 재부팅하면 다시 열려 있거나 다시 막혀 있죠. 이유는 간단합니다. 런타임 규칙과 영구 저장 규칙을 분리해서 이해하지 않았기 때문입니다. 배포판마다 iptables-persistent나 별도 서비스 관리 방식이 다를 수 있으니, 현재 서버가 어떤 방식으로 규칙을 유지하는지 먼저 확인하셔야 합니다.

    6. 네트워크 베스트 프랙티스: 제가 지금은 이렇게 운영합니다

    네트워크 베스트 프랙티스는 거창한 게 아닙니다. 사고를 줄이는 습관에 가깝습니다. 1년 동안 리눅스 서버를 굴려보니 아래 원칙이 가장 효과가 좋았습니다.

    항목 예전 방식 지금 방식
    설정 변경 한 번에 수정 단계별 변경 후 즉시 검증
    방화벽 정책부터 변경 허용 규칙 먼저 적용
    DNS 안 되면 아무 파일이나 수정 현재 resolver 구조부터 확인
    netplan 바로 apply generate, try 후 적용
    운영 기록 기억에 의존 변경 로그를 간단히 남김
    • 변경 전 현재 상태를 텍스트로 저장해 둡니다.
    • 운영 서버는 콘솔 접근 수단을 반드시 확보합니다.
    • DNS와 라우팅을 분리해서 테스트합니다.
    • 보안 강화를 할 때는 서비스 영향도를 먼저 봅니다.
    • 재부팅 후에도 유지되는지 꼭 확인합니다.

    혹시 이런 경험 있으신가요? 설정은 맞는 것 같은데, 재부팅 한 번 하고 나면 갑자기 안 되는 상황이요. 그런 경우는 대부분 “현재 세션에만 반영된 상태”와 “영구 설정 파일”이 다를 때가 많습니다. 저도 처음엔 헷갈렸는데, 이 구분만 해도 리눅스 네트워크 설정 실패 문제 절반은 줄어듭니다.

    iptables 실수 방지를 위한 리눅스 네트워크 설정 실패 예방 이미지

    SSH 허용 규칙을 먼저 넣고 기본 정책을 나중에 적용하는 안전한 iptables 흐름을 설명하는 이미지입니다.

    7. 검증 방법: 적용 후 무엇을 확인해야 하나

    설정이 들어갔다고 끝이 아닙니다. 검증이 빠지면 다음 장애 때 원인을 다시 처음부터 찾게 됩니다.

    1. 링크 상태: 인터페이스가 UP인지 확인합니다.
    2. 주소 확인: IP와 서브넷이 의도대로 붙었는지 봅니다.
    3. 라우팅 확인: default route가 맞는지 확인합니다.
    4. 이름 해석: DNS 질의가 정상인지 테스트합니다.
    5. 포트 확인: 서비스가 실제로 바인딩됐는지 확인합니다.
    6. 외부 접속: 다른 장비에서 실제 접속 테스트를 합니다.
    ip -brief address
    ip route
    getent hosts github.com
    ss -tulpen
    journalctl -u systemd-networkd --since "10 minutes ago"

    저는 여기에 하나를 더 합니다. 바로 “재부팅 검증”입니다. 지금 당장 되느냐보다, 다음 부팅에서도 그대로 올라오느냐가 운영에서는 더 중요하거든요.

    IP, 라우팅, DNS, 포트 상태를 체크리스트 형태로 확인하는 검증 결과 이미지를 넣는 자리입니다.

    8. 자주 묻는 질문과 정리

    Q1. ping이 되면 네트워크는 정상 아닌가요?

    꼭 그렇지는 않습니다. ICMP는 되는데 TCP 포트가 막혀 있을 수 있고, IP는 되는데 DNS 설정이 안 될 수도 있습니다. 그래서 계층별로 봐야 합니다.

    Q2. netplan만 쓰면 리눅스 네트워크 설정 문제가 다 해결되나요?

    아닙니다. netplan은 선언형 설정 도구일 뿐이고, 실제 렌더러가 networkd인지 NetworkManager인지도 봐야 합니다. 도구를 맹신하면 오히려 원인 파악이 늦어집니다.

    Q3. iptables와 nftables 중 무엇을 써야 하나요?

    배포판과 운영 환경에 따라 다릅니다. 중요한 건 이름보다도 현재 시스템이 어떤 프레임워크를 실제로 쓰는지 확인하는 겁니다. 혼용된 상태에서 규칙을 만지는 게 더 위험하더라고요.

    리눅스 네트워크 설정 실패를 줄이는 가장 좋은 방법은 천재적인 설정이 아니라, 평범한 검증 습관입니다. 저도 1년 동안 서버를 굴리면서 별별 문제를 다 겪었는데, 결국 살아남는 방법은 백업, 단계별 적용, 즉시 검증이었습니다. 다음 글에서는 방화벽 정책을 서비스별로 나누는 방법이나, 홈랩 기준 VLAN 분리 전략도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 확인 습관과 함께 보시면 더 도움이 되실 겁니다.

    리눅스 서버 운영에서 네트워크 베스트 프랙티스를 한눈에 정리한 요약 인포그래픽 이미지입니다.

    정리하자면 이렇습니다.

    • 리눅스 네트워크 설정 실패는 대부분 기본 개념보다 적용 순서와 검증 부족에서 시작됩니다.
    • iptables 실수는 규칙 순서와 영구 저장 여부를 먼저 확인하셔야 합니다.
    • DNS 설정은 resolver 구조를 이해하고 나서 건드려야 덜 꼬입니다.
    • netplan 문제는 YAML 문법과 NIC 이름 확인이 핵심입니다.
    • 네트워크 베스트 프랙티스는 결국 안전한 변경 절차를 습관으로 만드는 일입니다.
  • [보안] OPNsense 보안 강화 체크리스트: 홈랩부터 소규모 오피스까지

    [보안] OPNsense 보안 강화 체크리스트: 홈랩부터 소규모 오피스까지

    [보안] OPNsense 보안 강화 체크리스트: 홈랩부터 소규모 오피스까지

    홈랩이나 소규모 오피스를 운영하다 보면, 방화벽 한 대가 사실상 네트워크 전체의 신뢰 경계선이 되더라고요. 그래서 OPNsense 보안 강화는 그냥 있으면 좋은 옵션이 아니라, 사고를 줄이기 위한 기본 작업에 가깝습니다. 저도 처음엔 인터넷만 잘 되면 된다고 생각했는데, 실제로 써보니 관리 GUI가 외부에 너무 쉽게 열려 있거나, 불필요한 포트가 남아 있거나, 로그를 확인하지 않는 상태가 생각보다 흔했습니다. 이 글에서는 제가 홈랩과 소규모 환경에서 반복적으로 적용하는 체크리스트 중심의 방법을 정리해보겠습니다.

    특히 네트워크 보안, 서버 하드닝, 방화벽 설정 관점에서 바로 적용할 수 있게 구성했습니다. 복잡한 이론보다, “지금 당장 뭘 확인해야 하나?”에 초점을 맞췄습니다.

    OPNsense 방화벽 보안 강화 전체 아키텍처 다이어그램

    홈랩과 소규모 오피스 환경에서 WAN, LAN, 관리망, VPN 구간이 분리된 OPNsense 보안 강화 아키텍처 예시입니다.

    1. 왜 OPNsense 보안 강화가 중요한가

    쉽게 말해 방화벽은 외부 진입(Ingress)과 내부 전송(Egress)을 통제하는 문지기입니다. 이 문지기 설정이 느슨하면 내부 서버를 아무리 잘 꾸며도 의미가 반쯤 사라지거든요.

    제가 직접 해보니 홈랩은 특히 더 방심하기 쉽습니다. 테스트용 포트를 잠깐 열어뒀다가 그대로 두거나, 관리자 페이지를 편하다고 아무 대역에서나 접속 가능하게 두는 경우가 많았습니다. 소규모 오피스도 비슷합니다. 사람이 적다고 위협이 적은 건 아니더라고요. 오히려 장비 수는 적은데 운영자가 바빠서 기본 점검이 밀리는 경우가 많았습니다.

    • 관리 인터페이스 노출 최소화
    • 기본 허용보다 명시적 허용
    • 로그와 알림 체계 확보
    • 원격 접속은 VPN 중심으로 전환

    이 네 가지만 잡아도 체감 보안 수준이 꽤 올라갑니다.

    2. OPNsense 보안 강화 핵심 개념

    여기서 중요한 포인트! OPNsense를 잘 쓴다는 건 기능을 많이 켜는 게 아니라, 공격면(Attack Surface, 공격 가능한 노출 지점)을 줄이는 쪽으로 생각하는 겁니다.

    2-1. 기본 거부(Default Deny, 기본 차단)

    필요한 것만 열고 나머지는 막는 방식입니다. 처음엔 답답해 보이는데, 장기적으로는 이게 훨씬 편합니다. 규칙이 왜 존재하는지 설명이 가능해지거든요.

    2-2. 최소 권한(Least Privilege, 최소 권한)

    관리자 계정도 꼭 필요한 사람만, 꼭 필요한 네트워크에서만 접근하게 해야 합니다. 관리자 GUI, SSH, API 모두 같은 원칙으로 보시면 됩니다.

    2-3. 구간 분리(Segmentation, 네트워크 분리)

    서버, 사용자 단말, IoT, 게스트 Wi-Fi를 한 대역에 몰아넣으면 문제 생겼을 때 옆으로 전파되기 쉽습니다. VLAN(가상 LAN, 논리적 네트워크 분리)이나 별도 인터페이스로 나누는 이유가 바로 이겁니다.

    2-4. 가시성(Visibility, 가시성 확보)

    막는 것도 중요하지만, 무엇이 막혔고 무엇이 통과했는지 보이는 게 더 중요할 때가 많습니다. 실제로 장애인지 공격인지 구분하려면 로그가 있어야 하거든요.

    항목 개선 전 권장 구성
    관리 GUI 접근 LAN 전체 허용 관리용 대역 또는 관리 호스트만 허용
    원격 관리 포트포워딩으로 직접 노출 VPN 뒤에서만 접근
    규칙 작성 Any to Any 다수 사용 출발지/목적지/포트 명시
    로그 문제 생길 때만 확인 상시 점검 및 중요 이벤트 알림

    3. 실전 체크리스트: 초기 하드닝 순서

    이제 실제로 적용해보겠습니다. 아래 순서는 제가 새로 구축할 때 거의 그대로 따르는 흐름입니다.

    1. 관리자 계정 비밀번호 재설정과 불필요한 계정 제거
    2. 관리 GUI 포트와 접근 대역 제한
    3. SSH 비활성화 또는 관리망으로 제한
    4. WAN 측 불필요 서비스 비노출 확인
    5. 방화벽 규칙 정리와 Any 규칙 제거
    6. 아웃바운드 정책 검토
    7. VPN 우선 원격 접속 구조로 변경
    8. 로그, 백업, 업데이트 절차 정착

    3-1. 관리 접근 제한

    가장 먼저 볼 부분입니다. OPNsense 웹 관리 화면은 편하지만, 그만큼 노출되면 위험합니다. 가능하면 관리용 VLAN 또는 특정 관리 PC에서만 붙게 만드세요.

    # 예시 점검 항목 메모
    # 1) 관리 GUI는 내부 관리망에서만 접속 가능해야 함
    # 2) WAN 인터페이스에서 GUI/SSH 응답이 없어야 함
    # 3) 관리자 계정은 강한 비밀번호 또는 추가 인증 사용
    
    # 외부에서 포트 응답 여부 확인 예시
    nc -zv firewall.example.local 443
    nc -zv firewall.example.local 22

    실제로 써보니까 “관리 편의성” 때문에 예외를 하나씩 열다 보면 나중엔 왜 열었는지 기억도 안 나는 규칙이 생기더라고요. 그래서 규칙 설명(Description)을 꼭 남기는 습관이 중요합니다.

    3-2. 네트워크 분리와 별도 존(Zone) 운영

    저는 최소한 아래처럼 나누는 편입니다.

    • Management: 방화벽, 스위치, 하이퍼바이저 관리망
    • Server: NAS, VM, 컨테이너 호스트
    • User: 노트북, 데스크톱
    • IoT: 카메라, 스마트홈 장비
    • Guest: 방문자 네트워크

    혹시 이런 경험 있으신가요? IoT 장비 하나 붙였는데 내부 NAS까지 보여서 깜짝 놀란 적이요. 저도 처음엔 헷갈렸는데, 분리만 해도 마음이 훨씬 편해집니다.

    관리망과 사용자망, IoT망이 분리된 OPNsense 인터페이스 구성 화면 또는 네트워크 세그먼트 다이어그램

    관리망, 서버망, 사용자망, IoT망을 분리해 방화벽 정책을 다르게 적용하는 구성 예시입니다.

    3-3. 규칙은 좁게, 설명은 자세히

    OPNsense 베스트 프랙티스 중 하나는 규칙을 좁게 쓰는 겁니다. Any to Any는 테스트 순간엔 편한데, 운영 단계로 넘어가면 빚이 됩니다.

    # 클라이언트에서 특정 서비스 연결 확인
    curl -I http://192.168.10.20
    curl -k https://192.168.10.30
    
    # DNS 확인
    dig example.com @192.168.10.1
    
    # 라우팅/연결성 확인
    traceroute 8.8.8.8

    규칙 예시는 이런 식으로 생각하시면 됩니다.

    1. 출발지(Source): User VLAN의 특정 대역
    2. 목적지(Destination): 내부 DNS 또는 프록시 서버
    3. 포트(Port): 53, 80, 443 등 필요한 포트만
    4. 설명(Description): 왜 필요한지 기록

    4. 원격 접속은 포트포워딩보다 VPN 우선

    여기서 많이 갈립니다. 집 밖에서 관리해야 하니까 포트포워딩으로 관리자 페이지를 바로 여는 경우가 있는데, 저는 권장하지 않습니다. 가능하면 WireGuard(경량 VPN)나 OpenVPN(가상사설망) 뒤에서 접근하는 구조가 낫습니다.

    제가 홈랩에서 여러 번 바꿔보니, 초반엔 귀찮아도 장기적으로는 VPN 방식이 훨씬 덜 불안합니다. 외부에 보이는 건 VPN 포트 하나로 줄고, 관리 GUI는 내부 대역에서만 열리게 유지할 수 있거든요.

    # VPN 연결 후 관리 GUI 접근 확인 예시
    ping 192.168.50.1
    curl -k https://192.168.50.1
    
    # VPN 연결 상태에서만 관리자 대역 접근 허용 여부 점검
    ssh [email protected]

    물론 VPN도 설정이 허술하면 의미가 없습니다. 계정 관리, 키 관리, 불필요한 사용자 제거는 꼭 같이 보셔야 합니다.

    5. 로그, 알림, 백업까지 묶어야 진짜 운영입니다

    방화벽 설정은 해놓고 끝이 아니더라고요. 시간이 지나면 규칙이 누적되고, 누가 뭘 바꿨는지 흐려집니다. 그래서 저는 보안 강화를 할 때 운영 체크리스트까지 한 묶음으로 봅니다.

    • 로그 확인 주기를 정합니다
    • 중요 규칙 차단 로그는 남기되, 과도한 로그 폭주는 피합니다
    • 설정 백업을 정기화합니다
    • 업데이트 전 백업을 습관화합니다
    • 변경 기록을 남깁니다

    특히 소규모 오피스는 “누가 마지막으로 바꿨는지”가 진짜 중요합니다. 저도 예전에 규칙 하나 바뀐 걸 놓쳐서 반나절을 본 적 있습니다. 그때 느꼈죠. 로그 없으면 감입니다, 운영이 아니라.

    OPNsense 로그 모니터링과 방화벽 이벤트 대시보드 화면 스타일의 시각화

    차단 로그, 허용 로그, VPN 접속 이벤트를 한눈에 보는 검증용 대시보드 이미지 위치입니다.

    6. ⚠️ 실제로 자주 겪는 문제와 해결법

    이 섹션은 경험담 중심으로 작성했습니다. 처음엔 이게 뭔가 싶었는데, 결국 반복되는 패턴이 있더라고요.

    6-1. 관리 GUI가 갑자기 안 열리는 경우

    원인: 관리 대역 제한 규칙을 너무 빡빡하게 걸었거나, 적용 순서가 꼬인 경우가 많습니다.

    해결: 콘솔 접근 경로를 미리 확보해두세요. 물리 콘솔이나 하이퍼바이저 콘솔이 있으면 복구가 훨씬 빠릅니다. 원격에서만 작업하면 진짜 식은땀 납니다.

    6-2. DNS는 되는데 웹 접속이 이상한 경우

    원인: 아웃바운드 규칙, MTU 관련 이슈, 프록시 또는 업스트림 DNS 정책 충돌일 수 있습니다.

    해결: DNS, ICMP, TCP 443 순으로 단계적으로 확인하세요. 한 번에 전체를 보려고 하면 더 헷갈립니다.

    6-3. IoT 분리 후 앱 연동이 깨지는 경우

    원인: 멀티캐스트, 브로드캐스트 탐색, 제조사 앱의 로컬 검색 방식 때문입니다.

    해결: 무조건 다 열지 말고, 필요한 프로토콜만 예외로 두는 방향이 좋습니다. 여기서 성급하게 Any 허용 넣으면 다시 원점입니다.

    6-4. 차단 로그가 너무 많아 못 보는 경우

    원인: 인터넷 백그라운드 스캔, 잡음 많은 클라이언트, 과도한 로깅 설정

    해결: 모든 규칙을 다 로깅하지 말고, 의미 있는 구간만 남기세요. WAN 인바운드 차단, VPN 인증 실패, 관리망 접근 시도 같은 이벤트가 우선입니다.

    7. 검증 방법: 설정 후 꼭 확인할 것

    OPNsense 보안 강화는 설정 자체보다 검증이 더 중요합니다. 제가 실제로 점검할 때 보는 항목은 아래와 같습니다.

    1. WAN에서 관리자 페이지가 보이지 않는지 확인
    2. 허용한 내부 서비스만 통신되는지 확인
    3. VLAN 간 불필요한 횡적 이동이 막히는지 확인
    4. VPN 연결 후에만 관리망 접근이 되는지 확인
    5. 차단 로그와 허용 로그가 의도대로 남는지 확인
    # 포트 스캔 예시
    nmap -Pn -p 22,53,80,443,1194,51820 firewall.example.local
    
    # 내부 구간 접근 테스트 예시
    curl http://192.168.20.10:8080
    curl http://192.168.30.10:8080
    
    # 외부에서 차단 여부 확인
    nc -zv public.example.com 443
    nc -zv public.example.com 22

    이거 진짜 편하더라고요. 한 번 체크리스트로 정리해두면 다음 구축 때 속도가 훨씬 빨라집니다. 감으로 보던 걸 재현 가능한 절차로 바꾸는 셈이니까요.

    OPNsense 보안 강화 전후 비교표와 체크리스트 요약 인포그래픽

    보안 강화 전후의 관리 노출 범위, 규칙 수, 접근 방식 차이를 요약한 인포그래픽 이미지 위치입니다.

    8. 정리: 홈랩과 소규모 오피스에서 먼저 할 일

    마무리해보겠습니다. OPNsense 보안 강화는 거창한 기능 추가보다, 기본을 지키는 작업에 가깝습니다. 관리 노출 줄이고, 네트워크 분리하고, 규칙을 좁게 쓰고, VPN 뒤에서 관리하고, 로그와 백업을 운영 절차에 넣는 것. 이 다섯 가지가 핵심입니다.

    • 관리 GUI와 SSH는 가능한 한 제한하세요
    • 서버망, 사용자망, IoT망은 분리하세요
    • Any 규칙은 테스트 후 반드시 정리하세요
    • 원격 관리는 VPN 우선으로 바꾸세요
    • 로그, 백업, 업데이트 절차를 같이 운영하세요

    저도 처음엔 방화벽 설정을 “인터넷만 되면 끝” 정도로 생각했었는데, 시간이 지나고 나니 결국 서버 하드닝과 방화벽 설정은 함께 가야 한다는 걸 많이 느꼈습니다. 다음 글에서는 VLAN 분리 이후 실제 서비스별 허용 규칙 설계, 예를 들면 NAS, Proxmox, Docker 호스트 같은 장비를 어떻게 안전하게 묶을지 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 분리 내용이 있다면 함께 보셔도 흐름이 잘 이어질 겁니다.

    9. 자주 묻는 질문

    Q1. 홈랩에도 이렇게까지 해야 하나요?

    제 경험상, 오히려 홈랩이라서 더 기본기를 잡아두는 게 좋았습니다. 실험이 많아 예외 규칙이 늘기 쉽거든요.

    Q2. 관리자 페이지를 외부에서 바로 열면 정말 안 되나요?

    아예 불가능하다고 단정하긴 어렵지만, 저는 권장하지 않습니다. VPN 뒤로 숨기는 쪽이 훨씬 보수적이고 운영도 깔끔했습니다.

    Q3. 로그는 얼마나 남겨야 하나요?

    모든 걸 다 남기기보다, 보안적으로 의미 있는 이벤트 위주가 낫습니다. 차단 이벤트, 원격 접속, 관리 접근 시도부터 시작해보세요.

    결국 체크리스트가 답입니다. 한 번 잘 만들어두면 다음 구축이 쉬워지고, 장애나 보안 이슈가 생겨도 어디부터 볼지 명확해지거든요. 그게 제일 큰 차이였습니다. 🎉

  • [Game] 테라리아/ARK 서버 접속 불가? 흔한 포트포워딩 및 방화벽 문제 해결법

    [Game] 테라리아/ARK 서버 접속 불가? 흔한 포트포워딩 및 방화벽 문제 해결법

    [트러블슈팅] 게임 서버 접속 오류, 테라리아/ARK 포트포워딩과 방화벽부터 점검하세요

    집에서 테라리아 서버나 ARK 서버를 열어놨는데, 내 PC에서는 잘 되는데 친구만 못 들어오는 경우가 있죠. 이럴 때 가장 흔한 원인이 바로 포트포워딩(Port Forwarding, 공유기에서 내부 장치로 트래픽을 넘기는 설정)과 방화벽(Firewall, 허용되지 않은 통신을 막는 보안 장치)입니다. 저도 처음엔 게임 설정 문제인 줄 알고 한참 삽질했었는데, 막상 원인은 네트워크 쪽이더라고요. 오늘은 게임 서버 접속 오류가 날 때 어디부터 봐야 하는지, 특히 테라리아와 ARK 기준으로 실전에서 바로 써먹을 수 있는 확인 순서를 정리해보겠습니다.

    중요한 포인트는 단순합니다. 서버 프로세스가 실제로 떠 있는지, 운영체제 방화벽이 포트를 열어줬는지, 공유기가 해당 포트를 내부 서버 PC로 전달하는지, 마지막으로 통신사가 외부 인바운드 연결을 막는 환경은 아닌지를 순서대로 보면 됩니다. 이 순서를 무시하고 여기저기 건드리면 저처럼 시간만 날릴 수 있습니다 ㅎㅎ

    게임 서버 접속 오류 원인을 설명하는 홈 네트워크와 포트포워딩 구조 이미지

    인터넷, 공유기, 서버 PC, 외부 플레이어가 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.

    1. 왜 내 컴퓨터에서는 되고 친구는 안 될까요?

    쉽게 말해, 같은 집 안에서 접속되는 것과 인터넷 밖에서 접속되는 것은 완전히 다른 문제입니다. 내 PC나 같은 LAN(Local Area Network, 내부망)에서는 서버의 사설 IP로 붙을 수 있습니다. 그런데 외부 친구는 공인 IP를 통해 공유기까지 들어온 뒤, 공유기가 정확한 내부 서버 PC로 연결을 넘겨줘야 하거든요.

    여기서 자주 헷갈리는 개념을 표로 정리해보면 이렇습니다.

    항목 의미 자주 생기는 문제
    사설 IP 집 안 장치에 할당되는 내부 주소 서버 PC IP가 바뀌면 포트포워딩 대상이 틀어짐
    공인 IP 인터넷에서 보이는 외부 주소 잘못된 IP를 친구에게 전달함
    포트 서비스별 통신 창구 게임 포트와 포워딩 포트가 다름
    방화벽 들어오고 나가는 통신 제어 프로그램은 실행 중인데 접속은 차단됨
    NAT 공유기가 내부/외부 주소를 변환 NAT 구조를 몰라 외부 접속이 막힘

    혹시 이런 경험 있으신가요? 친구는 접속 실패인데, 나는 localhost나 192.168.x.x 주소로 잘 들어가집니다. 이건 게임이 고장 난 게 아니라, 외부에서 내부 서버까지 들어오는 길이 안 열려 있는 상황인 경우가 많습니다.

    2. 테라리아 서버, ARK 서버에서 먼저 확인할 개념

    테라리아 서버와 ARK 서버는 둘 다 외부 클라이언트가 서버가 열어둔 포트로 들어와야 합니다. 다만 게임마다 쓰는 포트와 프로토콜(TCP/UDP)이 다를 수 있습니다. 여기서 중요한 건 숫자를 무작정 외우는 게 아니라, 내가 실제로 실행한 서버 설정 파일이나 실행 옵션에서 어떤 포트를 쓰는지 확인하는 습관입니다.

    그래도 많이 쓰는 예시는 알고 있으면 편합니다.

    • Terraria: 기본 예시로 7777 포트를 많이 사용합니다.
    • ARK: 환경에 따라 다르지만 게임 포트와 쿼리 포트(query port)를 함께 여는 경우가 많습니다.
    • 프로토콜: 게임마다 TCP, UDP 중 하나 또는 둘 다 필요할 수 있습니다. 서버 문서나 실행 로그를 반드시 같이 보셔야 합니다.

    제가 직접 해보니 여기서 많이 틀립니다. 공유기에는 7777만 열었는데, 실제 서버는 다른 포트로 떠 있거나, ARK 쪽은 쿼리 포트를 안 열어서 서버 목록에 안 보이는 식이더라고요. 게임 서버 접속 오류가 났다면, 제일 먼저 “서버가 실제로 어느 포트에서 리슨(listen, 연결 대기) 중인가?”를 확인해보세요.

    3. 실전 점검 1단계: 서버 프로세스와 리슨 포트 확인

    가장 먼저 할 일은 게임 서버 프로그램이 정상 실행 중인지 보는 겁니다. 실행 창이 떠 있다고 끝이 아니고, 운영체제에서 실제로 포트를 열고 대기 중이어야 합니다.

    Linux에서 확인하는 방법

    ss -tulpen | grep -E '7777|27015'
    

    또는 구형 환경이면 아래처럼 볼 수 있습니다.

    netstat -tulpen | grep -E '7777|27015'
    

    출력에서 LISTEN 또는 UDP 소켓이 보이면 일단 서버가 포트를 잡고 있는 겁니다.

    Windows에서 확인하는 방법

    netstat -ano | findstr :7777
    netstat -ano | findstr :27015
    

    PID가 보이면 작업 관리자(Task Manager)나 아래 명령으로 어떤 프로세스인지 연결해볼 수 있습니다.

    tasklist /FI "PID eq 1234"
    

    여기서 아무것도 안 나온다면, 포트포워딩 이전에 서버 자체가 제대로 안 떠 있는 겁니다. 설정 파일 경로가 틀렸거나, 저장 경로 권한 문제거나, 이미 다른 프로그램이 같은 포트를 쓰고 있을 수 있습니다.

    테라리아 서버와 ARK 서버 포트 리슨 상태를 확인하는 터미널 점검 이미지

    실제 점검 과정에서 가장 먼저 보는 화면입니다. 포트가 열려 있는지부터 확인해야 다음 단계가 의미가 있습니다.

    4. 실전 점검 2단계: 운영체제 방화벽 열기

    서버가 떠 있어도 방화벽 설정이 막고 있으면 외부 접속은 안 됩니다. 저도 예전에 공유기 설정만 한참 만지다가, 결국 Windows Defender Firewall에서 차단 중인 걸 보고 허탈했던 적이 있습니다.

    Windows Defender Firewall 예시

    관리자 권한 PowerShell 또는 명령 프롬프트에서 아래처럼 인바운드 규칙을 추가할 수 있습니다.

    netsh advfirewall firewall add rule name="Terraria TCP 7777" dir=in action=allow protocol=TCP localport=7777
    netsh advfirewall firewall add rule name="Terraria UDP 7777" dir=in action=allow protocol=UDP localport=7777
    netsh advfirewall firewall add rule name="ARK UDP 7777" dir=in action=allow protocol=UDP localport=7777
    netsh advfirewall firewall add rule name="ARK UDP 27015" dir=in action=allow protocol=UDP localport=27015
    

    실제 포트는 여러분 서버 설정에 맞게 바꾸셔야 합니다.

    Ubuntu의 UFW(Uncomplicated Firewall) 예시

    sudo ufw allow 7777/tcp
    sudo ufw allow 7777/udp
    sudo ufw allow 27015/udp
    sudo ufw status verbose
    

    firewalld 예시

    sudo firewall-cmd --permanent --add-port=7777/tcp
    sudo firewall-cmd --permanent --add-port=7777/udp
    sudo firewall-cmd --permanent --add-port=27015/udp
    sudo firewall-cmd --reload
    sudo firewall-cmd --list-ports
    

    여기서 중요한 포인트! 서버 프로그램을 예외 처리할지, 포트 자체를 열지 방식이 갈릴 수 있는데, 홈랩에서는 포트 기준으로 명확하게 여는 방식이 나중에 추적하기 편했습니다. 어떤 포트를 왜 열었는지 기록도 남기 좋거든요.

    5. 실전 점검 3단계: 공유기 포트포워딩 설정

    이제 포트포워딩을 봅니다. 쉽게 말해 외부에서 들어온 7777번 요청을, 내부의 192.168.0.10 같은 서버 PC IP로 넘겨주는 규칙입니다. 공유기 제조사마다 메뉴 이름은 조금씩 다르지만 보통 Port Forwarding, Virtual Server, NAT, Applications 같은 이름으로 들어가면 나옵니다.

    1. 서버 PC의 현재 내부 IP를 확인합니다.
    2. 가능하면 DHCP Reservation(고정 할당)으로 서버 IP가 바뀌지 않게 묶습니다.
    3. 외부 포트와 내부 포트를 게임 서버 포트에 맞춰 입력합니다.
    4. 프로토콜을 TCP, UDP 또는 둘 다로 정확히 지정합니다.
    5. 대상 IP를 서버 PC 내부 IP로 설정합니다.
    6. 저장 후 공유기 재적용 또는 재부팅을 합니다.

    예를 들어 이런 식입니다.

    서비스명 외부 포트 내부 IP 내부 포트 프로토콜
    Terraria 7777 192.168.0.10 7777 TCP 또는 설정값 기준
    ARK Game 7777 192.168.0.10 7777 UDP 예시
    ARK Query 27015 192.168.0.10 27015 UDP 예시

    공유기 웹 UI에서 메뉴를 찾기 어렵다면, 핵심은 하나입니다. 외부에서 들어온 특정 포트를 내부 서버 장치로 전달하는 기능을 찾으면 됩니다. 메뉴 이름이 달라도 원리는 같습니다.

    포트포워딩 설정으로 게임 서버 접속 오류를 해결하는 공유기 설정 이미지

    실제 공유기 화면은 제조사마다 다르지만, 외부 포트를 내부 서버 IP로 연결하는 구조는 거의 비슷합니다.

    6. ⚠️ 많이 막히는 지점: 이중 공유기, CGNAT, 잘못된 테스트 방식

    여기가 진짜 핵심입니다. 게임 서버 접속 오류를 잡을 때 포트포워딩과 방화벽을 다 맞췄는데도 안 되는 경우가 있거든요. 저도 처음엔 이게 뭔가 싶었는데, 알고 보니 네트워크 구조 자체가 문제였습니다.

    1) 이중 공유기(Double NAT, NAT 두 번)

    통신사 장비 뒤에 개인 공유기를 또 물려 쓴다면, 포트포워딩을 두 군데 다 해야 할 수 있습니다. 예를 들어 통신사 장비가 192.168.0.x 대역이고, 내 공유기가 192.168.1.x 대역이면 이미 NAT가 한 번 더 있는 구조일 가능성이 큽니다.

    • 증상: 설정은 다 맞는 것 같은데 외부 접속만 안 됨
    • 확인: 내 공유기의 WAN IP가 사설 IP인지 확인
    • 해결: 브리지 모드(Bridge Mode)나 DMZ, 또는 상위 장비에도 포워딩 설정

    2) CGNAT(Carrier-Grade NAT, 통신사 공유 공인망)

    일부 인터넷 환경에서는 아예 집에 직접 공인 IP가 안 들어오는 경우가 있습니다. 이 경우 일반적인 포트포워딩만으로는 외부에서 직접 접속이 안 됩니다.

    • 증상: 공유기 WAN 주소가 공인 IP처럼 안 보임
    • 해결: 통신사에 공인 IP 제공 여부 문의, 또는 VPN/WireGuard/Tailscale 같은 우회 구조 검토

    3) 내부에서 공인 IP로 테스트

    이것도 자주 틀립니다. 같은 집 안에서 내 공인 IP로 접속 테스트했는데 실패했다고 해서, 외부 접속이 반드시 안 되는 건 아닙니다. 공유기마다 NAT loopback(내부에서 외부 주소로 다시 들어오는 동작) 지원 여부가 다르거든요. 그래서 모바일 데이터나 외부 네트워크에서 테스트해야 정확합니다.

    4) 서버 IP가 바뀜

    DHCP로 서버 PC IP가 바뀌면, 공유기 포워딩이 옛날 IP를 보고 있어서 갑자기 접속이 끊깁니다. 어제까지 되다가 오늘 안 되면 이 경우가 꽤 많습니다.

    제가 실제로 써보니까, 홈랩에서는 서버 장비만큼은 고정 IP 또는 DHCP Reservation을 꼭 걸어두는 게 마음 편하더라고요.

    7. 검증 방법: 어디까지 열렸는지 단계별로 보기

    설정을 끝냈다면 이제 감으로 보지 말고 검증해야 합니다. 아래 순서대로 보면 문제 구간이 꽤 빨리 좁혀집니다.

    1. 로컬 테스트: 서버 PC에서 localhost 또는 내부 IP로 접속
    2. 같은 집 내부 테스트: 다른 PC/기기에서 사설 IP로 접속
    3. 외부 테스트: 모바일 데이터 또는 다른 장소 네트워크에서 공인 IP로 접속
    4. 포트 개방 점검: 외부 포트 체크 도구 또는 실제 클라이언트 접속 시도
    5. 로그 확인: 서버 콘솔에 접속 시도 흔적이 남는지 보기

    로그에 접속 흔적조차 없으면, 대부분 서버 앞단인 방화벽 설정 또는 포트포워딩 문제입니다. 반대로 로그는 찍히는데 게임에서 튕긴다면, 버전 불일치나 모드 충돌, 세이브 파일 문제 같은 애플리케이션 레벨을 봐야 합니다.

    ipconfig
    ip addr
    ss -tulpen | grep 7777
    sudo ufw status verbose
    

    Windows 환경이라면 아래도 같이 보세요.

    ipconfig
    netstat -ano | findstr :7777
    netsh advfirewall firewall show rule name=all | findstr 7777
    
    외부 네트워크에서 테라리아 서버와 ARK 서버 접속을 검증하는 결과 이미지

    외부 환경에서 실제 접속이 되는지 확인하는 장면입니다. 내부 테스트만으로는 놓치는 문제가 꽤 많습니다.

    8. 정리와 FAQ: 테라리아 서버, ARK 서버 접속 안 될 때 체크리스트

    마지막으로 빠르게 훑을 수 있게 체크리스트 형태로 정리해보겠습니다. 저는 이런 식으로 하나씩 지우면서 봅니다. 의외로 가장 단순한 항목에서 끝나는 경우가 많더라고요.

    • 서버 프로세스가 실제로 실행 중인가?
    • 서버가 원하는 포트에서 리슨 중인가?
    • 운영체제 방화벽에서 해당 포트를 허용했는가?
    • 공유기 포트포워딩 대상 IP가 현재 서버 IP와 같은가?
    • 프로토콜 TCP/UDP를 맞게 설정했는가?
    • 이중 공유기 또는 CGNAT 환경은 아닌가?
    • 외부 네트워크에서 테스트했는가?
    • 서버 로그에 접속 시도 흔적이 남는가?

    자주 묻는 질문

    Q. 테라리아 서버는 켜져 있는데 친구가 못 들어옵니다.
    A. 서버가 7777 같은 예상 포트가 아니라 다른 포트로 떠 있을 수 있습니다. 먼저 리슨 포트를 확인하고, 그 포트 기준으로 방화벽과 포트포워딩을 다시 맞춰보세요.

    Q. ARK 서버가 목록에 안 보입니다.
    A. 게임 포트만 열고 쿼리 포트를 빼먹는 경우가 있습니다. 서버 실행 옵션과 문서를 같이 보고 필요한 포트를 모두 열었는지 확인해보세요.

    Q. 포트 개방 사이트에서는 닫힘인데, 뭘 봐야 하나요?
    A. 서버 프로세스가 해당 포트에서 대기 중인지, 방화벽이 막고 있지 않은지, 그리고 외부 테스트가 정확한 네트워크에서 이루어졌는지 순서대로 보셔야 합니다.

    결국 게임 서버 접속 오류는 복잡해 보여도 흐름은 같습니다. 서버 실행 → OS 방화벽 → 공유기 포트포워딩 → 외부 테스트. 이 순서만 지켜도 원인을 훨씬 빨리 찾습니다. 다음 글에서는 홈랩 기준으로 WireGuard VPN이나 리버스 프록시(reverse proxy, 요청을 대신 받아 내부 서비스로 넘기는 구성) 같은 대안 접근도 다뤄볼 예정입니다. 이전 글에서 다룬 홈서버 네트워크 기본편과 함께 보시면 이해가 더 빨라집니다.

    포트포워딩과 방화벽 설정 체크리스트로 게임 서버 접속 오류를 정리한 인포그래픽

    마지막 점검용 요약 이미지입니다. 실제 장애 대응 때는 이런 체크리스트 한 장이 제일 도움이 됩니다.

  • [HomeLabs] MikroTik 라우터 1년 사용 회고: 홈랩 네트워크의 장단점 분석

    [HomeLabs] MikroTik 라우터 1년 사용 회고: 홈랩 네트워크의 장단점 분석

    [홈랩] MikroTik 라우터 1년 사용 회고

    MikroTik 라우터를 홈랩 네트워크 중심에 두고 1년 정도 운영해보니, 왜 이 장비가 입문자에게는 어렵고 익숙해지면 꽤 강력하다는 평가를 받는지 몸으로 이해하게 되더라고요. 처음엔 메뉴도 많고 용어도 낯설어서 솔직히 좀 당황했어요. 그런데 VLAN(가상 LAN, 논리적으로 분리된 네트워크), Firewall(방화벽, 트래픽 제어 규칙), Queue(큐, 대역폭 제어) 같은 기능을 하나씩 붙여보니까 홈랩 네트워크를 꽤 정교하게 다듬을 수 있었거든요. 혹시 집에서 서버 몇 대 굴리다가 네트워크가 점점 복잡해진 경험 있으신가요? 그 시점부터는 일반 공유기와는 다른 접근이 필요해지더라고요.

    이번 글은 특정 신제품 소개가 아니라, 제가 실제로 MikroTik RouterOS 환경을 홈랩에 적용하면서 느낀 장단점을 정리한 회고에 가깝습니다. 네트워크 장비 비교 관점에서도 어디가 좋았고 어디서 삽질했는지 솔직하게 적어보겠습니다. 다음 글에서는 스위치와 AP(Access Point, 무선 접속 장치)까지 포함한 전체 홈랩 네트워크 분리 설계를 더 자세히 다룰 예정입니다.

    MikroTik 라우터 중심의 홈랩 네트워크 아키텍처 다이어그램

    홈랩 네트워크에서 MikroTik 라우터가 코어 역할을 하는 전체 구성 예시입니다.

    MikroTik 라우터가 홈랩 네트워크에 잘 맞는 이유

    쉽게 말해 MikroTik 라우터는 공유기처럼 보이지만 운영 방식은 작은 네트워크 장비에 더 가깝습니다. 일반 가정용 장비가 버튼 몇 개로 끝나는 대신, MikroTik은 거의 모든 걸 세세하게 건드릴 수 있게 열어둔 느낌입니다. 처음엔 이게 뭔가 싶었는데, 홈랩처럼 요구사항이 자꾸 늘어나는 환경에서는 이 유연성이 진짜 크게 느껴지더라고요.

    제가 체감한 핵심 개념

    • RouterOS: MikroTik 장비에서 동작하는 네트워크 운영체제입니다. GUI와 CLI를 모두 지원해서 취향대로 작업할 수 있어요.
    • Bridge(브리지): 여러 포트를 하나의 스위치처럼 묶는 개념입니다. VLAN 필터링과 함께 많이 써요.
    • VLAN: 서버, 관리망, IoT 기기를 논리적으로 나누는 데 좋습니다.
    • NAT(Network Address Translation, 주소 변환): 내부 네트워크가 외부 인터넷에 나갈 때 거의 기본으로 들어갑니다.
    • Firewall Filter: 어떤 트래픽을 허용하고 막을지 정하는 핵심 규칙입니다.

    제가 직접 써보니 가장 큰 장점은 한 대로 할 수 있는 범위가 넓다기본값을 이해하지 못한 채 만지면 금방 헷갈린다

    1년 동안 운영하면서 느낀 장점과 단점

    항목 좋았던 점 아쉬웠던 점
    설정 유연성 세부 정책을 직접 설계하기 좋음 초기 진입장벽이 높음
    홈랩 네트워크 분리 VLAN, 방화벽 정책 구성에 유리 개념 이해 없이 설정하면 통신 장애가 남
    운영 도구 CLI, WinBox, Web UI 등 선택지가 있음 메뉴가 많아 처음엔 길을 잃기 쉬움
    문서/커뮤니티 검색하면 사례가 제법 나옴 설정 방식이 다양해서 정답이 하나가 아님
    확장성 VPN, 라우팅, QoS까지 확장 가능 기능이 많아질수록 관리 기준이 필요함

    특히 홈랩 네트워크에서는 서버망, 개인 PC망, IoT망을 나누는 순간부터 MikroTik 라우터의 진가가 나옵니다. 반대로 인터넷만 되면 되는 환경이라면 너무 과할 수도 있어요. 여기서 중요한 포인트! 좋은 장비가 아니라, 요구사항에 맞는 장비가 좋은 장비라는 점입니다.

    실전 구현: 제가 홈랩에서 잡았던 기본 구조

    제 환경에서는 아주 복잡하게 시작하지 않았어요. 처음부터 BGP(Border Gateway Protocol, 경로 제어 프로토콜) 같은 걸 만진 건 아니고요. 아래처럼 단순한 목표부터 잡았습니다.

    1. WAN과 LAN 기본 연결
    2. 관리용 네트워크와 일반 사용자 네트워크 분리
    3. 서버용 VLAN 추가
    4. 인터넷은 허용하되 관리망 접근은 제한
    5. 필요한 서비스만 포트 전달

    실제로 써보니까 처음부터 모든 걸 자동화하려고 하기보다, 기본 연결 → VLAN → 방화벽 → 모니터링 순서가 훨씬 덜 꼬였어요.

    예시 1: 인터페이스와 주소 기본 구성

    /interface bridge
    add name=bridge-lan vlan-filtering=yes
    
    /interface bridge port
    add bridge=bridge-lan interface=ether2
    add bridge=bridge-lan interface=ether3
    add bridge=bridge-lan interface=ether4
    
    /ip address
    add address=192.168.10.1/24 interface=bridge-lan comment=main-lan
    
    /ip pool
    add name=pool-main ranges=192.168.10.100-192.168.10.199
    
    /ip dhcp-server
    add name=dhcp-main interface=bridge-lan address-pool=pool-main
    
    /ip dhcp-server network
    add address=192.168.10.0/24 gateway=192.168.10.1 dns-server=192.168.10.1

    이 단계는 말 그대로 뼈대예요. 여기서 DHCP(Dynamic Host Configuration Protocol, 자동 IP 할당)까지 붙여두면 최소한 네트워크는 살아나거든요. 드디어 됐다! 싶은 첫 구간이 바로 여기였습니다.

    예시 2: VLAN 분리

    /interface vlan
    add interface=bridge-lan name=vlan20-servers vlan-id=20
    add interface=bridge-lan name=vlan30-iot vlan-id=30
    
    /ip address
    add address=192.168.20.1/24 interface=vlan20-servers comment=servers
    add address=192.168.30.1/24 interface=vlan30-iot comment=iot

    서버망과 IoT망을 나누고 나면 체감이 커요. NAS(Network Attached Storage, 네트워크 스토리지)나 가상화 호스트가 있는 구간은 좀 더 보수적으로 관리할 수 있고, IoT 기기 쪽은 인터넷만 나가게 제한하는 식으로 설계하기 쉬워지거든요.

    MikroTik RouterOS VLAN 및 인터페이스 구성 개념 이미지

    VLAN과 브리지 포트가 어떻게 연결되는지 한눈에 보이는 설정 개념도입니다.

    예시 3: 기본 방화벽 정책

    /ip firewall filter
    add chain=input action=accept connection-state=established,related
    add chain=input action=drop connection-state=invalid
    add chain=input action=accept protocol=icmp
    add chain=input action=accept src-address=192.168.10.0/24
    add chain=input action=drop
    
    add chain=forward action=accept connection-state=established,related
    add chain=forward action=drop connection-state=invalid
    add chain=forward action=accept src-address=192.168.20.0/24 dst-address=192.168.10.0/24
    add chain=forward action=drop src-address=192.168.30.0/24 dst-address=192.168.10.0/24
    add chain=forward action=accept

    여기서 많이 배우게 돼요. 라우터 자신에게 들어오는 트래픽은 input, 네트워크를 통과하는 트래픽은 forward라는 기본 구조를 이해해야 규칙이 덜 꼬여요. 저도 처음엔 forward만 만지다가 왜 관리 접속이 막히는지 한참 헤맸거든요.

    운영하면서 자주 썼던 점검 명령어

    설정도 중요하지만 검증이 더 중요해요. 홈랩 네트워크는 바뀌는 일이 많아서, 바꿀 때마다 확인 루틴을 만들어두는 게 훨씬 편하더라고요.

    /ip address print
    /interface bridge port print
    /interface vlan print
    /ip route print
    /ip firewall filter print stats
    /ping 8.8.8.8
    /tool traceroute 1.1.1.1

    특히 print stats는 규칙이 실제로 맞고 있는지 확인할 때 유용했어요. 규칙은 예쁘게 써놨는데 카운터가 안 올라가면 방향을 잘못 잡은 경우가 많았거든요.

    ⚠️ 주의사항과 제가 실제로 겪은 트러블슈팅

    MikroTik RouterOS를 1년 정도 굴리면서 가장 많이 한 삽질은 세 가지였어요. 이 부분은 정말 초반에 알았으면 시간을 꽤 아꼈을 겁니다.

    1. VLAN 태깅 방향을 헷갈리기 쉬움

    브리지, 포트, VLAN 테이블 관계를 정확히 안 보면 특정 포트만 통신이 안 되는 일이 생겨요. 처음엔 DHCP가 왜 안 붙지 싶었는데, 실제 원인은 태그드(tagged)와 언태그드(untagged) 포트 구분이 어긋난 경우가 많았습니다.

    • 증상: 특정 장비만 IP를 못 받음
    • 원인: 포트 PVID(기본 VLAN ID)와 브리지 VLAN 항목 불일치
    • 해결: VLAN 설계도를 먼저 그리고 포트 역할을 표로 정리

    2. 방화벽 규칙 순서가 생각보다 중요해요

    Firewall Filter는 위에서 아래로 평가되기 때문에, 넓게 허용하는 규칙을 먼저 두면 뒤쪽 차단 규칙이 사실상 의미가 없어져요. 이거 정말 많이 놓쳐요. 저도 초반엔 규칙은 다 써놨는데 왜 안 막히지? 하고 한참 봤습니다.

    3. 관리 접근 경로를 따로 남겨두는 게 안전해요

    원격에서만 만지다가 규칙 실수로 접속이 끊기면 꽤 난감해요. 가능하면 초기 작업은 로컬에서 하고, 관리망을 따로 두는 편이 좋습니다. 백업(export)도 자주 해두세요.

    /export file=backup-before-firewall
    /system backup save name=router-backup

    백업은 귀찮아도 무조건입니다. 한 번 꼬이면 다시 치는 시간보다 백업 복원이 훨씬 빨라요.

    MikroTik 라우터 방화벽 규칙과 트러블슈팅 흐름도

    입력 체인과 포워드 체인을 구분해 문제를 찾는 트러블슈팅 흐름 예시입니다.

    검증: 1년 운영 후 체감한 결과

    검증은 거창한 벤치마크보다 운영 안정성 관점에서 봤어요. 수치를 지어내고 싶진 않아서, 제가 실제로 중요하게 본 기준만 적겠습니다.

    1. 네트워크 분리 후 실수 전파 범위가 줄었는가
    2. 새 서버를 붙일 때 정책 적용이 쉬운가
    3. 문제 발생 시 원인 추적이 가능한가
    4. 재부팅이나 설정 변경 후 복구가 빠른가

    결론부터 말하면, 홈랩 네트워크 운영 피로도는 줄었어요. 예전에는 장비가 늘어날수록 규칙이 머릿속에서만 관리됐는데, MikroTik 라우터로 옮긴 뒤에는 네트워크 경계가 좀 더 명확해졌거든요. 서버망은 서버망대로, IoT는 IoT대로 성격에 맞는 정책을 적용하기 쉬웠습니다.

    물론 단점도 남았어요. 설정 자유도가 높다는 건, 결국 운영자 책임도 커진다는 뜻이거든요. 대충 만들어도 돌아가는 구성보다는, 명확하게 설계한 구성이 훨씬 잘 버텨요. 이건 RouterOS 자체보다 네트워크 장비 비교 전반에 적용되는 이야기 같아요.

    MikroTik 라우터 기반 홈랩 네트워크 모니터링 대시보드

    분리된 VLAN, 트래픽 흐름, 장비 상태를 확인하는 운영 관점의 결과 이미지입니다.

    네트워크 장비 비교 관점에서 본 MikroTik의 포지션

    많이들 궁금해하시는 포인트가 이거죠. 그래서 일반적인 비교 기준으로 정리해봤습니다.

    비교 기준 MikroTik 라우터 일반 가정용 공유기 소형 x86 방화벽 장비
    초기 난이도 높은 편 낮은 편 중간 이상
    세부 제어 강함 제한적 강함
    홈랩 네트워크 적합성 매우 좋음 단순 환경에 적합 고급 구성에 적합
    학습 가치 높음 낮음 높음
    운영 편의성 익숙해지면 좋음 매우 쉬움 구성에 따라 다름

    제 기준에서는 이런 분께 잘 맞았어요.

    • 집에서 서버, NAS, 가상화 환경을 운영하는 분
    • VLAN과 방화벽을 직접 만져보고 싶은 분
    • CLI와 GUI를 오가며 배우는 걸 싫어하지 않는 분

    반대로 그냥 인터넷 잘 되고 와이파이만 안정적이면 되는 분에게는 과할 수 있어요. 장비의 문제가 아니라 요구사항의 문제죠.

    정리: 1년 써보니 이런 분께 추천합니다

    1년 동안 써본 회고를 한 줄로 줄이면 이렇습니다. MikroTik 라우터는 쉬운 장비는 아니지만, 홈랩 네트워크를 제대로 설계하고 싶은 사람에게는 꽤 오래 가져갈 만한 도구예요. 저도 처음엔 메뉴가 너무 많아서 멈칫했는데, 한 번 구조가 잡히고 나니까 “아, 이래서들 쓰는구나” 싶더라고요.

    특히 MikroTik RouterOS는 네트워크를 공부하면서 운영까지 같이 해볼 수 있다는 점이 좋았어요. 단순히 인터넷 연결 장비가 아니라, 설계하고 검증하는 연습장처럼 느껴졌거든요. 이게 홈랩 재미이기도 하고요.

    다음 단계로는 아래 순서로 확장해보시면 좋습니다.

    1. 기본 LAN 구성부터 안정화
    2. 서버망과 IoT망 VLAN 분리
    3. 방화벽 정책 최소 허용 원칙 적용
    4. VPN과 원격 관리 구성
    5. 모니터링과 백업 자동화

    이전 글에서 다뤘던 홈랩 백업 전략과도 연결되는 주제라, 내부 링크로 묶어보셔도 좋을 것 같아요. 다음 글에서는 AP와 스위치까지 포함한 전체 홈랩 네트워크 설계 흐름을 더 현실적으로 정리해보겠습니다.

    MikroTik 라우터 1년 사용 장단점 요약 인포그래픽

    1년 사용 기준으로 정리한 장점, 단점, 추천 대상 요약 이미지입니다.

    자주 묻는 질문

    Q1. MikroTik 라우터는 초보자에게 너무 어렵지 않나요?

    처음엔 어려워요. 다만 홈랩 네트워크를 배우려는 목적이라면 오히려 배울 게 많습니다. 단, 한 번에 다 하려 하지 말고 기본 연결부터 쌓아가시는 게 좋아요.

    Q2. GUI만으로도 운영 가능한가요?

    가능합니다. 다만 CLI를 조금이라도 같이 보면 설정 구조 이해가 빨라져요. 저는 WinBox로 구조를 보고, CLI로 정리하는 식이 제일 편했습니다.

    Q3. 네트워크 장비 비교 시 가장 먼저 볼 기준은 뭔가요?

    내가 원하는 분리 수준과 운영 방식이에요. VLAN이 필요한지, 방화벽 정책을 직접 관리할지, 추후 확장 가능성이 있는지를 먼저 보시는 게 맞습니다.

  • [보안] 방화벽 설정, 이것만은 꼭! 10가지 필수 점검 항목

    [보안] 방화벽 설정, 이것만은 꼭! 10가지 필수 점검 항목

    [보안] 방화벽 설정, 이것만은 꼭! 10가지 필수 점검 항목

    서버를 올리고 포트만 열어둔 뒤 불안했던 경험, 아마 한 번쯤 있으실 겁니다. 저도 홈랩에서 테스트 서버를 굴리다가 방화벽 설정을 대충 해두고 넘어갔다가 나중에 로그를 보고 식은땀을 흘린 적이 있거든요. 방화벽 설정은 단순히 포트를 열고 닫는 작업이 아니라, 네트워크 보안의 기본선(baseline, 최소 보안 기준)을 만드는 일입니다. 이번 글에서는 실무와 홈랩에서 반복해서 확인하는 방화벽 보안 체크리스트 중심으로, 꼭 봐야 할 필수 점검 항목 10가지를 정리해보겠습니다.

    특히 이 글은 “방화벽 설정 후 뭘 먼저 확인해야 하지?” 하고 막막하신 분들을 위해 썼습니다. Linux 서버 기준 예시를 넣겠지만, 원칙 자체는 온프레미스(on-premise, 사내 구축 환경), 클라우드, 가상화 환경 모두에 그대로 적용됩니다.

    방화벽 설정이 적용된 홈랩 네트워크 아키텍처 이미지

    방화벽 설정 점검 항목이 DMZ, 내부망, 관리망으로 나뉘어 보이는 전체 개요 이미지입니다.

    1. 왜 방화벽 설정 점검은 항상 사고 전에 해야 할까요

    방화벽(Firewall, 트래픽을 제어하는 보안 장치)은 평소엔 조용합니다. 그래서 더 무섭습니다. 문제가 생기기 전까지는 존재감이 없거든요. 그런데 실제 장애나 침해사고 대응에서는 거의 항상 “이 포트 왜 열려 있었지?”, “관리 포트가 왜 외부에 노출됐지?” 같은 질문이 나옵니다.

    제가 직접 경험해보니 방화벽 설정 검토는 잘한 티는 안 나는데, 한 번 놓치면 문제가 됩니다. 특히 다음 상황에서 실수가 많이 나옵니다.

    • 테스트 서버를 운영 서버처럼 오래 끌고 갔을 때
    • 임시 오픈한 포트를 닫지 않았을 때
    • 소스 IP 제한 없이 관리 포트를 공개했을 때
    • 클라우드 보안 그룹(Security Group, 가상 방화벽)과 OS 방화벽 정책이 따로 놀 때

    여기서 중요한 포인트는 이것입니다: 방화벽은 “설정해뒀다”보다 “지금도 맞는 상태인지 확인하는 것”이 더 중요합니다.

    2. 좋은 방화벽 설정의 기본 원칙

    좋은 방화벽 설정은 결국 한 문장으로 정리됩니다: 필요한 통신만 허용하고, 나머지는 기본 차단(Default Deny, 기본 거부)하는 상태입니다. 이 원칙 하나만 제대로 잡아도 절반은 갑니다.

    방화벽 설정 점검 기준은 세 가지로 보면 편합니다.

    1. 누가 들어오나: 소스 IP, 네트워크 대역
    2. 어디로 들어오나: 목적지 포트, 서비스
    3. 왜 열어두나: 실제 업무 필요성, 운영 근거

    결국 방화벽 설정은 ACL(Access Control List, 접근 제어 목록)을 얼마나 명확하게 관리하느냐의 문제더라고요. “웹 서비스라서 80/443 허용”, “운영자만 SSH 22 접근”, “DB 3306은 앱 서버만 허용” 이런 식으로요.

    3. 방화벽 설정 점검 체크리스트: 필수 10가지 항목

    아래 10가지는 제가 서버 오픈 전에 거의 습관처럼 확인하는 필수 점검 항목입니다. 이 순서로 보면 빠르고, 빠뜨릴 것도 줄어듭니다.

    항목 무엇을 확인하나 핵심 이유
    1 기본 정책(Default Policy) 미정의 트래픽 차단
    2 허용 포트 최소화 공격 표면 축소
    3 관리 포트 접근 제한 SSH, RDP 등 보호
    4 소스 IP 대역 제한 불필요한 외부 접근 차단
    5 인바운드/아웃바운드 구분 양방향 정책 명확화
    6 불필요한 Any 허용 제거 과도한 허용 방지
    7 로그 활성화 추적과 감사 가능
    8 규칙 우선순위 확인 예상과 다른 매칭 방지
    9 예외 정책 문서화 운영 지속성 확보
    10 검증 명령과 정기 점검 설정 드리프트 방지

    보안 체크리스트는 화려할 필요 없습니다. 대신 반복 가능해야 합니다. 그리고 누가 봐도 같은 결론이 나와야 합니다.

    10가지 필수 항목을 짧게 풀어보면

    • 기본 정책은 deny: 허용보다 차단을 기본값으로 둡니다.
    • 포트는 최소한만: 서비스와 무관한 포트는 닫습니다.
    • 관리 포트는 외부 전체 공개 금지: Bastion(배스천, 중계 관리 서버)이나 VPN 뒤로 넣는 게 좋습니다.
    • 소스 제한: 가능하면 특정 사무실 IP나 관리망만 허용합니다.
    • 아웃바운드도 본다: 내부 서버가 외부로 아무 데나 나가는 것도 위험할 수 있습니다.
    • Any-Any 규칙 제거: 편하지만 위험합니다. 저도 급할 때 열었다가 나중에 후회했었습니다.
    • 로그는 꼭 남긴다: 침해 대응의 시작점입니다.
    • 우선순위 확인: 먼저 걸리는 규칙 때문에 뒤 규칙이 무의미해질 수 있습니다.
    • 예외는 기록: 왜 열었는지 안 적어두면 몇 달 뒤 아무도 모릅니다.
    • 정기 검증: 월 1회만 해도 효과가 큽니다.

    4. 실전 구현: Linux 서버의 방화벽 설정 기본

    여기서는 Ubuntu 계열에서 많이 쓰는 UFW(Uncomplicated Firewall, 간단 방화벽 관리 도구) 기준으로 보여드리겠습니다. 환경에 따라 nftables(리눅스 패킷 필터 프레임워크)나 iptables(전통적 패킷 필터)를 쓰실 수도 있는데, 원칙은 같습니다.

    1. 현재 열려 있는 서비스와 포트를 먼저 확인합니다.
    2. 기본 정책을 설정합니다.
    3. 서비스별 허용 규칙을 최소 권한으로 추가합니다.
    4. 로그와 검증을 수행합니다.
    ss -tulpn
    sudo ufw status verbose
    sudo ufw default deny incoming
    sudo ufw default allow outgoing
    sudo ufw allow 80/tcp
    sudo ufw allow 443/tcp
    sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
    sudo ufw logging on
    sudo ufw enable
    sudo ufw status numbered

    위 예시는 정말 기본형입니다. 웹 서버라면 80/443만, SSH는 관리 IP에서만 허용하는 식이죠. 실제로 써보니까 처음부터 이렇게 보수적으로 잡는 게 나중에 훨씬 편하더라고요.

    서비스별 방화벽 설정 기준

    서비스 권장 접근 방식 비고
    SSH 특정 관리 IP만 허용 가능하면 VPN 뒤에서 접근
    HTTP/HTTPS 외부 공개 허용 리버스 프록시 뒤 구성 가능
    DB 포트 앱 서버 IP만 허용 인터넷 직접 공개 지양
    모니터링 포트 관리망만 허용 Prometheus 등 내부 수집 권장
    방화벽 설정에서 허용 포트를 구분한 서버 구성 이미지

    웹 포트와 관리 포트가 구분되어 보이는 실전 방화벽 설정 예시 이미지입니다.

    5. 더 실무적으로: 인바운드와 아웃바운드를 함께 점검하세요

    많이 놓치는 부분이 아웃바운드(Outbound, 서버에서 외부로 나가는 트래픽)입니다. 인바운드만 막아두면 끝이라고 생각하기 쉬운데, 실제 운영에서는 그렇지 않거든요. 만약 서버가 침해당했다면 외부 C2(Command and Control, 원격 제어 서버)와 통신을 시도할 수도 있습니다.

    그래서 저는 최소한 아래는 꼭 봅니다.

    • 패키지 저장소, 시간 동기화, 외부 API 등이 꼭 필요한 목적지인지
    • 내부 서버가 임의 포트로 외부에 나가고 있지 않은지
    • 백업, 모니터링, 알림 전송 경로가 정책과 충돌하지 않는지

    예를 들어 DB 서버는 인터넷으로 직접 나갈 이유가 거의 없습니다. 그런 서버는 아웃바운드 정책도 보수적으로 잡는 편이 낫습니다.

    sudo ufw default deny outgoing
    sudo ufw allow out 53
    sudo ufw allow out 123/udp
    sudo ufw allow out 443/tcp
    sudo ufw status verbose

    물론 이렇게 하면 처음엔 업데이트나 에이전트 통신이 막혀서 좀 삽질했습니다. ㅎㅎ 그래서 운영 서버에 바로 적용하기보다는, 먼저 필요한 통신 목록부터 뽑아보시는 걸 추천드립니다.

    6. 규칙 우선순위, 로그, 문서화: 운영 품질을 갈라놓는 세 가지

    방화벽 설정이 당장은 맞아 보여도, 시간이 지나면 예외 규칙이 늘어나면서 복잡해집니다. 그때 진짜 차이가 나는 게 규칙 우선순위(rule order), 로그(logging), 문서화(documentation)입니다.

    규칙 우선순위 확인하기

    특히 iptables나 클라우드 ACL에서는 먼저 매칭된 규칙이 적용되는 경우가 많습니다. 그래서 아래처럼 번호나 순서를 보고 정리해야 합니다.

    sudo ufw status numbered

    분명 차단 규칙을 넣었는데 접속이 되는 경험 있으신가요? 나중에 보면 위쪽에 더 넓은 허용 규칙이 먼저 있더라고요. 저도 처음엔 꽤 헷갈렸습니다.

    로그는 최소한 이 정도는 남기세요

    • 거부된 접속 시도
    • 관리 포트 접근 시도
    • 비정상적으로 반복되는 스캔 패턴

    로그가 있어야 Fail2ban 같은 자동 방어 도구를 붙이기도 쉽고, 나중에 보안 체크리스트 점검 결과를 설명하기도 편합니다.

    예외 정책은 꼭 기록하세요

    예를 들어 “협력사 고정 IP에서만 임시 허용, 만료일은 2026-08-03” 같은 걸 남겨야 합니다. 안 그러면 임시가 영구가 됩니다. 이거 진짜 자주 봅니다.

    방화벽 설정 결과를 모니터링하는 네트워크 보안 대시보드 이미지

    차단 로그와 관리 포트 접근 시도가 보이는 결과 검증용 모니터링 이미지입니다.

    7. ⚠️ 실제로 겪었던 문제들: 방화벽 트러블슈팅 포인트

    실무든 홈랩이든 방화벽 설정에서 가장 무서운 건 “서비스를 보호하려다가 내가 못 들어가는 상황”입니다. 저도 원격지 장비에서 SSH를 제 손으로 막아본 적 있습니다. “드디어 됐다!” 하고 나갔는데 다시 접속이 안 되더라고요.

    자주 겪는 문제 1: SSH를 너무 빨리 막음

    해결 방법은 간단합니다: 현재 접속 중인 세션을 유지한 상태에서 새 세션으로 재접속 테스트를 먼저 하세요.

    sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
    ssh user@server-ip

    새 세션 접속이 확인되기 전에는 기존 세션을 끊지 않는 게 안전합니다.

    자주 겪는 문제 2: 클라우드 방화벽과 OS 방화벽이 충돌

    AWS Security Group, GCP VPC Firewall, Azure NSG 같은 상위 정책과 OS 내부 정책이 둘 다 있으면, 어디서 막히는지 헷갈립니다. 이런 경우는 아래 순서로 확인하면 됩니다.

    1. 클라우드 보안 그룹에서 허용 여부 확인
    2. OS 방화벽에서 동일 포트 허용 여부 확인
    3. 서비스 데몬이 실제로 Listen(포트 대기) 중인지 확인
    4. 라우팅과 NAT(Network Address Translation, 주소 변환) 경로 확인
    ss -tulpn
    sudo ufw status verbose
    ip addr
    ip route

    자주 겪는 문제 3: IPv4만 보고 끝냄

    이 부분도 은근히 놓칩니다. IPv6이 활성화된 환경이라면 IPv4 규칙만 보고 안심하면 안 됩니다. 방화벽 설정 점검 시 IPv6 정책도 같이 봐야 합니다.

    8. 검증 방법: 설정했으면 반드시 확인하세요

    보안은 추측으로 끝내면 안 됩니다. 설정 후에는 꼭 검증해야 합니다. 저는 보통 서버 내부 확인과 외부 확인을 나눠서 봅니다.

    서버 내부에서 확인

    sudo ufw status verbose
    sudo ufw status numbered
    ss -tulpn
    • 열려 있어야 하는 포트만 열려 있는지
    • 허용 대상 IP가 의도와 맞는지
    • 기본 정책이 incoming deny인지

    외부에서 확인

    nc -vz server-ip 22
    nc -vz server-ip 80
    nc -vz server-ip 443

    관리 PC에서는 열려야 하고, 허용되지 않은 위치에서는 막혀야 정상입니다. 이 차이를 직접 확인해보면 훨씬 마음이 놓입니다.

    방화벽 설정 검증 체크리스트

    1. 기본 정책이 차단 중심인지 확인
    2. 불필요한 포트가 남아 있지 않은지 확인
    3. 관리 포트가 특정 IP로 제한됐는지 확인
    4. 로그가 남고 있는지 확인
    5. 예외 정책이 문서화됐는지 확인

    이 정도만 해도 네트워크 보안 수준이 꽤 안정됩니다. 화려한 장비보다 이런 기본기가 훨씬 오래 갑니다.

    방화벽 설정 필수 점검 항목을 요약한 네트워크 보안 이미지

    점검 전후 차이와 필수 점검 항목 10가지를 한눈에 보여주는 요약 이미지입니다.

    9. 정리: 방화벽 설정은 결국 운영 습관입니다

    정리하면 방화벽 설정의 핵심은 세 가지입니다: 기본 차단, 최소 허용, 지속 검증. 사실 특별한 비법은 없습니다. 대신 귀찮아도 반복해야 합니다. 저도 처음엔 규칙 몇 개 넣고 끝내려 했었는데, 시간이 지나 보니 결국 방화벽 보안 체크리스트를 얼마나 성실하게 돌리느냐가 차이를 만들더라고요.

    다음 글에서는 홈랩 기준으로 리버스 프록시(역방향 프록시)와 방화벽을 함께 구성하는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 모니터링 내용과 연결해서 보시면 더 이해가 쉬우실 겁니다.

    자주 묻는 질문

    Q. 방화벽 설정은 서버마다 다르게 해야 하나요?
    네, 서비스 역할이 다르면 달라져야 합니다. 웹 서버, DB 서버, 모니터링 서버는 필요한 포트와 접근 주체가 다르거든요.

    Q. 클라우드 보안 그룹만 있으면 OS 방화벽은 안 써도 되나요?
    환경에 따라 다르지만, 저는 이중으로 두는 편입니다. 방어 계층(다층 방어)이 생기기 때문입니다.

    Q. 제일 먼저 바꿔야 할 한 가지는 뭔가요?
    기본 정책을 정리하고, SSH 같은 관리 포트의 소스 IP 제한부터 거세요. 체감 효과가 가장 큽니다.

    마지막으로 한 줄만 드리면, 방화벽 설정은 한 번 잘해두는 작업이 아니라 계속 점검하는 운영 루�ine입니다. 오늘 서버 한 대라도 체크리스트대로 다시 보시면 분명 놓친 게 하나쯤은 보일 겁니다.