Remote Access
MikroTik IPsec 사이트 간 VPN 가이드
MikroTik IPsec 사이트 간 VPN 구축 방법: IKEv2 피어, 프로포절, 정책, 그리고 터널을 실제로 동작하게 하는 NAT 우회 규칙을 설정합니다.
요약 MikroTik IPsec 사이트 간 VPN은 두 네트워크 전체 사이의 트래픽을 암호화합니다. 본사와 지사, NOC와 기지국처럼 서로 떨어진 두 곳을 연결해, 각 LAN의 호스트가 상대편 호스트를 마치 로컬에 있는 것처럼 사용할 수 있게 합니다. 이 가이드에서는 RouterOS v7에서 양쪽 라우터를 모두 설정합니다. IKEv2 피어, 사전 공유 키 아이덴티티, Phase 2 프로포절, 터널 정책, 처음 시도할 때 대부분이 걸려 넘어지는 NAT 우회 규칙, 그리고 터널이 살아 있는지 확인하는 방화벽 규칙과 점검 방법을 다룹니다.
MikroTik IPsec 사이트 간 VPN이란?
MikroTik IPsec 사이트 간 VPN은 두 라우터 사이에 상시 유지되는 암호화 터널로, 분리된 두 LAN을 레이어 3에서 하나의 라우팅 가능한 네트워크로 묶어 줍니다. 이때 어느 쪽 라우터도 관리 포트를 공용 인터넷에 노출하지 않습니다. 관리자 장비 한 대가 접속하는 WireGuard나 OpenVPN 같은 클라이언트 접속형 VPN과 달리, 사이트 간 터널은 항상 연결되어 있고 서브넷 대 서브넷으로 동작합니다. 라우터 A 뒤의 모든 호스트가 라우터 B 뒤의 허용된 모든 호스트에 자동으로 도달할 수 있습니다. 여기서 IPsec이 적합한 이유는 사실상 모든 방화벽·라우터 제조사가 지원하는 개방형 표준이고, RouterOS 커널에서 동작해 처리량이 좋으며, MikroTik에서는 별도 패키지 설치 없이 기본 내장되어 있기 때문입니다.
터널은 두 번의 협상으로 만들어집니다. Phase 1(IKE)은 두 라우터가 서로를 인증하고 안전한 채널을 세웁니다. Phase 2(IPsec)는 실제 데이터 트래픽을 암호화할 키를 협상합니다. 양쪽 끝에서 두 단계가 모두 일치하면 터널이 올라옵니다. 알고리즘 하나만 어긋나도 아무 말 없이 실패합니다. 아래 단계에서 양쪽을 대칭으로 유지하는 이유가 바로 이것입니다.
시작하기 전에
RouterOS v7이 동작하는 MikroTik 라우터 두 대가 필요하며, 각 라우터에는 공인 IP 주소 또는 정상 동작하는 DDNS 호스트명이 있어야 합니다. 그리고 겹치지 않는 두 개의 LAN 서브넷이 필요합니다. 이 가이드는 Site A에 192.168.10.0/24, Site B에 192.168.20.0/24를 사용합니다. 두 사이트가 모두 192.168.88.0/24를 쓴다면 라우팅은 불가능하므로 한쪽 주소를 먼저 바꾸십시오. IPsec은 시간 오차에 매우 민감하므로 시작 전에 양쪽 라우터에서 NTP를 활성화하십시오. 양쪽 시계가 어긋나면 보안 연결(SA)이 만료되어 터널이 계속 끊깁니다.
이 전제 조건을 몇 개 이상의 사이트에서 관리하는 것만으로도 이미 번거로운 일입니다. 여러 대를 운영한다면 MKController가 터널을 넘기기 전에 각 라우터의 RouterOS 버전과 시간 소스를 하나의 콘솔에서 확인하게 해 주므로, 준비 상태를 보려고 장비마다 로그인할 필요가 없습니다.
1단계: IKE 프로파일과 피어 생성
Site A에서 Phase 1 프로파일을 정의하고 Site B의 공인 주소를 가리키는 피어를 추가합니다.
/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \ enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d
/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \ profile=to-siteB exchange-mode=ike2dh-group=modp2048은 Diffie-Hellman 그룹 14로, 견실한 최신 기본값입니다. exchange-mode=ike2는 IKEv2를 선택하며, 레거시 main/IKEv1 모드보다 빠르고 견고합니다. 양쪽 끝은 같은 프로파일 값과 같은 교환 모드를 사용해야 합니다.
2단계: 아이덴티티(사전 공유 키) 추가
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"길고 무작위한 시크릿을 사용하고 SSH 키를 다루듯 보관하십시오. 채팅 메시지에 남기지 마십시오. 같은 시크릿을 양쪽 라우터에 넣습니다.
3단계: Phase 2 프로포절 정의
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy(pfs-group)는 키를 갱신할 때마다 새로운 키 재료를 쓴다는 뜻입니다. 따라서 키가 유출되어도 과거 트래픽은 드러나지 않습니다. Phase 1과 마찬가지로 알고리즘은 양쪽 끝에서 일치해야 합니다.
4단계: 터널 정책 생성
정책은 어떤 트래픽을 암호화할지 RouterOS에 알려 줍니다. 즉 로컬 LAN에서 원격 LAN으로 가는 트래픽입니다.
/ip ipsec policy add peer=siteB tunnel=yes \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \ proposal=to-siteB action=encrypttunnel=yes가 이것을 호스트 대 호스트가 아닌 사이트 간 연결로 만드는 요소입니다. 원본 패킷이 통째로 감싸이므로 두 LAN이 투명하게 통신할 수 있습니다.
5단계: NAT 우회 규칙 추가(모두가 잊는 단계)
처음 시도가 깨지는 지점이 바로 여기입니다. 라우터에는 이미 나가는 LAN 트래픽의 출발지 주소를 바꾸는 masquerade 규칙이 있습니다. 그 규칙이 IPsec보다 먼저 동작하면, 원격 쪽은 출발지가 정책과 더 이상 맞지 않는 패킷을 받고 버립니다. 터널로 향하는 트래픽이 NAT를 건너뛰도록 masquerade 위에 accept 규칙을 추가하십시오.
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24place-before=0은 규칙을 srcnat 체인 맨 위에 놓습니다. 이는 필수입니다. masquerade 뒤에 놓인 우회 규칙은 아무 일도 하지 않습니다.
6단계: 방화벽 열기 및 확인
터널이 수립될 수 있도록 input 체인에서 IKE와 NAT-T 포트, 그리고 ESP 프로토콜을 허용하십시오. 어느 한 사이트가 다른 NAT 장비 뒤에 있다면 특히 중요합니다.
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=accept그런 다음 터널이 올라왔는지 확인합니다.
/ip ipsec active-peers print/ip ipsec policy print정상적인 터널이라면 활성 피어가 보이고 정책의 ph2-state가 established로 표시됩니다. 한쪽 LAN의 호스트에서 다른 쪽 LAN의 호스트로 핑을 한 번 보내면 종단 간 도달성을 확인할 수 있습니다.
Site B에서 설정 미러링하기
Site B에서는 주소를 뒤바꿔 모든 단계를 그대로 반복합니다. 피어는 Site A의 공인 IP를 가리키고, 정책과 NAT 우회는 src-address=192.168.20.0/24와 dst-address=192.168.10.0/24를 사용합니다. 프로파일, 프로포절, 아이덴티티 시크릿, IKEv2 모드는 동일하게 유지합니다. 양쪽이 일치하면 Phase 1과 Phase 2가 완료되고 터널이 올라옵니다.
보안 및 운영 팁
RouterOS를 최신 패치 상태로 유지하십시오. 최근 릴리스에는 IPsec/IKEv2 피어 인증서 매칭과 관련된 수정이 포함되었으므로, 지난 분기에 잘 돌던 터널도 업그레이드 후에는 재검증할 가치가 있습니다. 레거시 IKEv1 기본값보다 PFS를 적용한 IKEv2를 택하십시오. 가능하다면 터널 수가 늘어남에 따라 공유 시크릿에서 인증서 인증으로 옮겨 가십시오. 사전 공유 키 하나가 유출되면 그 키를 공유하는 모든 사이트가 영향을 받기 때문입니다. 그리고 터널 상태는 실제로 들여다보는 곳에 기록하십시오. 죽은 사이트 간 링크는 누군가 반대편 LAN에 접근하려다 실패하기 전까지는 보이지 않습니다.
여러 대를 운영할 때, 시간 동기화가 어긋나거나 WAN이 잠깐 끊긴 뒤 조용히 내려앉는 IPsec 터널은 딱 고객이 먼저 알아채는 종류의 장애입니다. MKController는 그 틈을 메웁니다. 장비에 공인 IP도 포트 포워딩도 필요 없는 안전한 아웃바운드 터널로 각 라우터를 지켜보고, 버전 관리되는 설정 백업을 보관해 잘못된 수정 뒤에도 동작하던 IPsec 블록을 비교하고 되돌릴 수 있으며, 링크 다운 이벤트가 발생하면 전화가 오기 전에 티켓을 열 수 있습니다. 터널 설정 자체에 대해서는 MikroTik의 NAT 가이드에서 여기서 우회하는 masquerade 규칙을 설명합니다. 두 LAN을 잇는 대신 라우터 한 대에 접속하려는 경우에는 CGNAT 뒤의 원격 관리와 WireGuard 원격 관리 문서를 참고하십시오.
모든 터널을 한 지붕 아래로
IPsec은 두 사이트를 깔끔하게 연결하지만, 성장하는 ISP나 MSP는 곧 수십 개의 터널과 키, 방화벽 규칙을 동기화된 상태로 유지해야 합니다. 그리고 모든 수동 수정은 원격 사이트에서 스스로를 잠가 버릴 기회가 됩니다. MKController는 정확히 그런 규모를 위해 만들어졌습니다. 중앙집중식 플릿 관리, 포트를 노출하지 않는 안전한 원격 접속, 설정 이력과 백업, 방화벽과 정책 변경의 플릿 전체 배포를 제공하므로 터널 템플릿을 라우터마다 다시 입력하는 대신 한 번에 배포할 수 있습니다. MikroTik을 대규모로 운영하는 사업자들은 장비별 SSH로 날리던 오후 한나절을 변경당 몇 번의 클릭으로 바꾸는 데 이를 사용합니다.