2026/08/01

[Korean] 오픈소스 B650 칩셋 카드 사용기 WisdPi PROM21

최근 WisdPi에서 AMD AM5소켓보드용 B650칩셋을 실장한 PROM21 확장카드를 입수하였다.

미리 언급하자면, 이 확장카드는 굉장히 마니악, niche한 제품이므로 용도를 잘 생각한 후 구매를 결정하기 바란다.



이 장치는 AMD B650 사우스브릿지를 PCIe 애드온 카드 형태로 외부화한 오픈소스를 구현한 제품이다. 즉, B650보드가 아닌 다른 메인보드에서 CPU와 사우스브릿지를 PCIe 4.0 x4 링크 하나로 호스트 시스템에 붙여버린 구조다.

이 글에서는 해당 카드의 아키텍처적 개요, PCIe 트리구조, 호환성 문제해결법, 성능, 그리고 왜 이런 물건을 사게되었는지까지의 과정과 장단점 내용을 담는다.


1. 아키텍처 개요 :  PCIe switch + USB + SATA + NVMe를 하나의 칩셋이 제공

일반적인 메인보드 칩셋과 기능은 완전히 동일하다. 단, BIOS레벨 RAID 기능은 제한적 환경에서만 쓸 수 있다.
  • PCIe 4.0 x4 업/다운링크
  • USB 3.2 gen2 10Gbps ×4
  • USB 3.2 gen2x2 20Gbps ×1
  • USB 2.0 480Mbps ×6
  • Oculink to SATA AHCI 4port or Oculink(U.2) 케이블 선택
  • 칩셋 RAID는 B650/X670/X870계열 메인보드에서만 UEFI펌웨어 메뉴가 노출 ※OS부팅 후 소프트웨어 RAID는 정상 동작

사실 AMD 건 인텔이건 칩셋은 사실 PCIe 스위치 + USB/SATA 컨트롤러 집합체다. 인텔은 자체적으로 설계하여 PCIe와 거의 같으면서도 다른 전용 프로토콜 DMI로 CPU와 연결되어 있을 뿐 역할은 같다. AMD의 경우, Asmedia에 설계외주로 발주하여 CPU의 IOdie와 통신을 전용 프로토콜이 아닌 일반적인 PCIe장치처럼 통신하게 된다. 따라서 B650칩셋이 AMD이외 시스템이건, 심지어 X86이 아닌 Arm시스템 (Mac, Raspberry Pi등)에도 드라이버 없이 잘 붙는다.

일반 컨슈머 시스템에는 고생없이 PCIe슬롯에 꽂아서 링크 트레이닝만 성공하면 동작한다. 하지만 시스템에 따라서는 이 링크 트레이닝이 잘 안되는 경우가 있을 수 있다.(내가 그랬다)

칩셋은 OS 입장에서 표준 USB 컨트롤러, 표준 AHCI, 표준 PCIe Root Port로 보이기에 각 OS표준 드라이버가 있다면 별도 설치하지 않아도 동작하며, OS는 “칩셋이 PCIe로 연결되었다”는 사실을 모르고 그저 새로운 Root Complex가 하나 더 생긴 것으로 인식한다.   


2. PCIe 트리 구조

SP3 또는 SP5 기반 EPYC은 원래 칩셋이 존재하지 않는 SoC 구조다. 칩셋이 없는 구조는 AMD 서버CPU 뿐만 아니라 AMD 또는 Intel 양사가 CPU 패키지 안에 SiP 구조 또는 완전한 원칩SoC로 통합했기에 딱히 신기한 구조는 아니다. 아직 CPU와 칩셋을 분리해 놓은 데스크탑용 CPU도 고전적인 순수CPU만 가지고 있는 것이 아니고, 기능이 여럿 통합된 SoC구조라서 내부에는 USB·SATA·메모리 컨트롤러를 포함해서 확장I/O용 PCIe Root Complex가 CPU 내부에 존재한다. 이런 점은 intel, AMD, Zhaoxin 같은 x86계를 넘어 심지어 Arm, Power계열에서도 다 똑같다.

CPU‑Z의 메인보드 화면에서 칩셋 항목이 SP3 SoC로 표시되는 것이 정상인데, 이 카드를 꽂으면 칩셋이 존재하지 않는 EPYC시스템에서 맨위의 화면과 같이 신기한 광경이 펼쳐진다.

  • CPU‑Z: X870 칩셋이 존재하는 것처럼 표시
  • (위의 변화로 인한 영향1) Windows는 메인보드 변경으로 판단 → PIN 로그인 초기화
  • (위의 변화로 인한 영향2) Windows 정품인증: Microsoft 계정 미연결 시 정품 인증 재요청

왜 이런 현상이 나는지에 앞서 사전지식으로, 칩셋은 ACPI device tree에 SB.PCI0.PCH0 같은 장치 노드를 생성한다. 여기서 SB는 사우스브릿지, PCI0는 CPU의 pcie루트 포트, PCH0가 칩셋이다. EPYC 플랫폼은 원래 PCH0 노드가 없는데, 카드가 자체적으로 ACPI 오브젝트를 생성해버린다. SB (system bus root) └─ PCI0 (PCIe root complex) : 0,1,2,3,4,... └─ PCH0 (칩셋. intel용어로 Platform Controller Hub)

즉, OS 입장에서 “메인보드 칩셋이 새로 생김 → 하드웨어 변경”으로 판단한다.


3. 호환성 문제 해결법

신기한 광경이 펼쳐지기는 한데 처음부터 잘 되는 건 아니다..

  • POST 단계에서 멈춤
  • Windows 로그인화면 직전에 아무 에러 메세지도 없이 재부팅
  • Linux의 dmesg 에러 남발 (PCIe AER, Link retrain 실패 등)

칩셋을 포함에 PCIe에 붙은 장치들에 대해 link training 과정에서 ASPM L1.1/L1.2를 사용한다. 하지만 일부 서버 보드에서 training과정이 실패하고, 칩셋 내부 컨트롤러가 초기화되지 않아서 위와 같은 문제가 발생한다. 에러를 잔뜩 뿜으면서 가까스로 부팅은 했지만, OS가 부팅 후 장치 재초기화를 제대로 할 수 없어 결과적으로 사용할 수 없는 상태가 지속된다.


이 문제를 해결하기 위해서는 아래 4가지를 시도해보자.

  • BIOS/BMC 업데이트
  • ACPI 옵션 OFF
  • ASPM 옵션 OFF

이렇게 해서 training이 정상적으로 이루어지면, 모든 기능이 안정적으로 동작한다. 안정적 동작이 확인된 후에는 위의 ACPI과 ASPM옵션을 켜도 될 것이다. 만약 다시 안된다면 옵션을 끄는 것이 좋다.


4. PROM21 카드의 PCIe 4.0 x4 대역폭 실제 성능

  • M.2 slot : 4개를 x4/0/0/0부터 x2/x2/0/0을 포함해 x1/x1/x1/x1까지 분배가능
    NVMe 1장 단일 구성은 약 7 GB/s에 업링크 한계에 근접
  • USB 20Gbps : 실측 약 1.8 GB/s
  • NVMe와 USB를 동시에 사용해도 업링크가 버팀
  • Oculink로 외부 연장가능
  • Oculink-SATA 4포트, 포트당 약 550 MB/s, 4개 풀로드 시 약 2.2 GB/s


5. 이 카드를 구입한 이유와 장단점

Supermicro H12SSL-NT은 USB 포트가 3.0 5Gbps 6개뿐이고 간혹 이유없이 먹통이 된다. 그래서 대안겸 가상화 패스스루가 잘된다는 리뷰를 토대로 포트당 Root Hub를 가진 Startech PEXUSB3S44V를 구입해 사용했지만 여러 문제가 있었다. 일반적인 메인보드에서는 아무 문제가 없다보니, 서버보드와 상성문제로 보인다.
  • H12SSL에서는 가끔 두 포트만 인식
  • UEFI 부팅 불안정
  • PCIe 리트레이닝 실패

USB4 카드는 Thunderbolt 제약(GPIO통신용 전용 포트가 필요) 때문에 장착 불가능했다. 안정적인 USB 남은 선택지가 사실상 이 B650 칩셋 카드뿐이었다. 다소 트러블 슈팅이 있었지만 현재는 supermicro H12SSL-NT보드에서 모든 기능이 정상동작하고 심지어 USB나 M.2포트를 통해 부팅도 가능한 것을 확인했기에 아주 만족하고 있다. 단점이라면, 가격에 거부감이 들 수 있다는 점이다. 26/8/1 현재 $199이며 B650보드가 더 저렴하게 팔리는 것을 생각하면 부품을 보유한 사람에 한해서는 비싸게 느껴질 것이다. 단 한가지 기능만 추가할 생각이라면 PROM21보다는 각 기능에 특화된 x4 대역폭에 적합한 확장카드 구입가격이 훨씬 저렴하다.

  • 대역폭은 작지만 PCIe2 x2를 x1 4포트 PCIe스위치를 aliexpress에서 저렴하게 구할 수 있다.
  • SATA만을 확장하고 싶다면 x8 SAS HBA를 사는 것이 성능/안정성/가격 면에서 좋다. 슬롯문제로 x4가 반드시 필요하다면 aliexpress에서 2.0 x4 16포트 확장카드도 저렴하게 구할 수 있다.
  • USB 10~20Gbps 확장카드도 저렴하게 구할 수 있다.
하지만 슬롯이 하나밖에 없는 상황에서 위의 모든 기능을 적당한 수량을 포함해서 확장하고 싶을 때에는 B650 칩셋제품이 압도적으로 유리하다. PCIe 3.0을 포함한 4.0 스위치는 많이 비싼 물건인데, B650은 물량의 힘으로 다기능 원칩을 싸게 공급할 수 있는 셈이다. 생각해보라, 과거 고급보드에서 PLX칩셋(PCIe 스위치 칩셋, 현재는 Broadcom에 인수합병)을 통해 PCIe슬롯을 확장할 수 있던 것에 비해 최신 고급보드에서 이 칩셋이 보이는가? 안보이는 이유는 PLX칩이 일반 메인보드가격의 몇 배나 되어 일반적인 메인보드에 가격문제로 도입을 할 수 없기 때문이다. x4배속용 칩이라도 매우 비싸다. 반면 PROM21 제품은 적당한 대역폭을 상대적으로 저렴한 가격에 M.2 4슬롯으로 마음만 먹으면 4.0 x1 (2GB/s) 대역폭으로 효율적으로 나눈 4슬롯에 의한 저속 I/O를 무한 확장을 할 수도 있다. 대부분의 M.2 bifurcation 확장슬롯카드가 x16용인 것을 감안하면, 이것도 활용하기에 따라서는 굉장한 가성비로 슬롯을 낭비하지 않으면서 쓸 수 있는 것이다.

  • m.2 1슬롯 SATA 3.0 (~500MB/s) 5포트확장.
  • m.2 4슬롯을 x1x1x1x1 설정하여 한 시스템에 x1 확장카드 4개 추가장착
  • 1080p60 또는 4K60 캡쳐보드 ※M.2 캡쳐보드 PCIe버전은 대부분 2.0 x1 or x2
  • Legacy용 시리얼포트 또는 프린터포트 대량확장 ※이런 것들은 거의 전부 PCIe 1.0 x1이다.
  • 드라이버가 필요없어서 Mac, Raspberry Pi 등 ARM시스템에서도 문제없이 동작한다.

6. 총평 — “외장형 PCH”라는 기괴한 구조가 의외로 실용적이다.

 장단점이 분명하게 존재하지만, 쓰임새에 따라서는 이만한 가성비도 없다.

이 카드는 사실상 ASMedia 기반 PCIe 스위치 + USB/SATA 컨트롤러 집합체이며, “외장형 PCH”라는 일반적이지 않은 구조에도 불구하고 정상적인 칩셋처럼 동작한다.

PCIe 4.0 스위치가 통상적으로 매우 비싸기 때문에, 이 카드는 적당한 대역폭의 PCIe 스위치를 저렴하게 대체하는 실용적 솔루션이 될 수 있다. 현재로서는 오픈소스로 자체제작을 제외하면 한두제품만 존재하여 상대적으로 비싼 감이 있지만, 추후 이런 옵션도 가능하다는 점이 붐이 일어서 가격이 떨어지기를 기대해 본다.

2026/03/15

[Korean] Mikrotik router의 내부 container 또는 하단 서브라우터에 tailscale 운용방법


최초작성: 2026/3/15
수정1: 2026/3/21
 - container 지원 ARM64 가장 저렴한 모델: L009 (ROS 7.22부터)

1. 서론

 Mikrotik 라우터를 15년 정도 사용해오면서 다수의 거점에 설치한 Mikrotik router를 site-to-site VPN연결을 L2TP-ipsec으로 운영해왔습니다만, 최근 android가 l2tp 지원을 없애버리는 바람에  Wireguard로 바꿨습니다. 

 Wireguard는 최근 엔트리 모델을 제외한 거의 모든 CPU가 쓸 수 있는 ipsec 하드웨어 암호화 가속의 지원을 받을 수 없는 대신 최신암호화 알고리즘을 사용하며 일반적으로 유명한 OS들이 지원하기 때문에 최신기기를 쓴다면 바꾸는 것이 좋습니다. 가볍고 정말 빠릅니다.

 그렇다고 Wireguard가 마냥 좋기만 한 건 아니고 L2TP에서 바꾸면서 불편했던 점 한가지는, OSI계층이 L2(MAC)이 아닌 L3(IP)방식이기 때문에 L2 네트워크 검색를 쓰는 소프트웨어에서 검색이 안됩니다. 그걸 감안하면 하드웨어가속이 없는데도 고속이며 간편하게 쓸 수 있는 장점이 있습니다.

 하지만 이것도 site-to-site를 연결하는 거점수가 적다면 편한데(이건 L2TP도 마찬가지입니다), 관리하는 거점수가 점점 많아지다보니 mesh VPN을 일일이 연결하기에는 많이 힘들고, 스크립트를 써서 하기에도 관리를 하자니 마땅한 대시보드가 없었습니다. 정말 이런 관리 대시보드 만드시는 분들 존경합니다.  그래서 찾다찾다 Wireguard기반의 mesh vpn을 자동생성하고, 관리 페이지에서 소프트웨어적으로 일원화된 패킷 제어 정책이 가능한 tailscale을 도입하고 싶었습니다. 

 Tailscale의 각 거점간 제어는 Tailscale 또는 Headscale 관리 페이지에서 하지만, 서로간의 실제 트래픽은 센터를 거치지 않고 P2P로 전송됩니다. 2026년 3월 현재 tailscale서비스는 3명의 user 및 100대 device까지 연결할 수 있어 개인 및 중소규모 용도로는 충분합니다. 그 이상의 경우는 오픈소스판 headscale 컨트롤러를 직접 설치해서 운영하거나 유료 플랜을 고려해 봐야 합니다.

 사실 Mikrotik에는 Tailscale대신 RouterOS 7부터 ARM32/ARM64/x86-64 CPU기종부터 Zerotier를 네이티브앱으로 지원하기 시작했습니다. Zerotier는 유저(클라이언트)측면에서 매우 설정이 간편하여 그냥 쓴다는 식의 개념이며, OSI L2로 인식하기 때문에(공식문서를 보면 엄밀히는 L1~L3를 애매하게 걸쳐있는 듯 합니다) MAC 기반의 검색이 가능해집니다. 가입해서 맛만 본 결과, 관리자측면으로는 상당히 복잡해서 쓰기 힘들었고, 결정적인 건 zerotier가 무료플랜이 빈약해서 Tailscale로 네트워크를 새로 구축했습니다. 아직 Mikrotik에는 네이티브 앱이 없어서 container를 직접 생성해서 돌리거나, Mikrotik 밑에 openwrt 등 서브라우터를 달아 Tailscale 커널모드로 돌릴 필요가 있습니다.

 그럼 지금부터 Tailscale의 서브라우터와 container설치 방법을 각각 알아보겠습니다. Mikrotik에서 돌아가는 tailscale은 kernel 모드 wireguard가 아닌 user space모드로 돌아가기 때문에 subnet router 기능 등이 정상적으로 동작하지 않을 수 있습니다. 확실한 동작을 위해서는 서브라우터에 openwrt나 리눅스등에 설치해서 사용하는 게 좋습니다.

2. Mikrotik 하단에 물리는 서브라우터에 Tailscale을 설치
3. Mikrotik 내부 container에 Tailscale을 설치


2. Mikrotik 하단에 물리는 서브라우터에 Tailscale을 설치(타사 공유기도 가능)

 되도록이면 3의 내부에 container로 돌려보고 싶은데 정 안되면 이 방법을 사용하시면 됩니다. 가상적으로 안되면 물리적으로 해결해버리는 게 가장 확실한 방법입니다. 저같은 경우에는 container와 L3 switch에 openwrt를 설치하고 tailscale을 올려서 여러개의 tailnet을 사용하고 있습니다. 

 사실 이 방법 자체는 메인 라우터가 꼭 mikrotik이 아니라 어떤 공유기라도 사용할 수 있으며 정적 라우팅에 한줄 추가해주는 것 만으로 똑같이 쓸 수 있습니다.

 개인적으로는 서브라우터에 openwrt luci 웹관리페이지를 올리고 소프트웨어 메뉴에서 업데이트 후 luci-app-tailscale-community 설치 및 재부팅해서 쓰는게 제일 간편하고 직관성있게 관리할 수 있어서 추천합니다.

 대부분 mikrotik이 내부에서 접근가능한 proxmox 등에 가상머신을 생성하여 tailscale을 설치하는 편이 간편하지만, 저전력으로 해결하고 싶다면 라즈베리파이 또는 안쓰는 오래된 라우터에 openwrt 등을 설치하고 tailscale을 설치하여 사용하는 방법이 주류입니다. 기본적으로 tailscale까지 설치하였다고 가정하고 라우터측 설정만 알아봅니다.

tailscale이 설치된 서브라우터의 ip 172.24.0.2

mikrotik 라우터의 ip 172.24.0.1


  -tailnet에 트래픽이 나갈 수 있도록 정적 라우팅(static routing)지정
   /ip/route add dst-address=100.64.0.0/10 gateway=172.24.0.2
   tailscale의 개인네트워크 주소대역 100.64.0.0/10으로 나가는 게이트웨이를 container를 통해서 나가게끔 지정하는 설정입니다. 이 설정이 없으면 라우터 밑에 물린 단말들이 tailnet 바깥으로 통신할 수 없습니다.

 Mikrotik 측에서는 설정이 이게 끝입니다. tailnet으로 향하는 트래픽만 전담으로 처리하는 서버를 지정하는 것만으로 tailnet과 통신할 수 있게됩니다. 만약 디폴트 게이트웨이를 tailnet으로 지정하고 exit node를 별도 지정할 경우 모든 트래픽이 VPN처럼 지나가게 됩니다. 이러한 예제가 apple tv나 아마존 fire tv스틱에 tailscale을 설치하고 VPN용도로 미국 또는 한국 전용 컨텐츠 시청을 위해 활용되고 있는 듯 보입니다.

3. Mikrotik 내부 container에 Tailscale을 설치

 3.1 Container-Tailscale 설치가 가능한 모델

 CPU 아키텍쳐: ARM64, X86, ARM32(초심자 비권장)
 ※초심자는 ARM32v5모델을 안쓰는 게 좋습니다. 
    hEX S(2025)를 포함해 공식홈페이지에 "ARM64"가 아닌 "ARM"으로 표시된 것을 말합니다.
    CPU자체가 ARM64지원해도 펌웨어가 32bit인 경우도 마찬가지로 컨테이너를 다루기 어렵습니다.

 CPU아키텍쳐는 Mikrotik 홈페이지의 하드웨어 스펙을 자세히 확인하시길 바랍니다.

 위의 3개 아키텍쳐 중 ARM32 CPU를 사용하는 router 모델은 arm32v5 아키텍쳐용 패키지 이미지를 다운로드 받아서 써야하는데, 대부분의 docker/github에서는 ARM32용을 arm32v7 이미지만 기본제공을 하고 Mikrotik  arm32 CPU용 arm32v5 패키지는 대부분 없어서 직접 이미지를 빌드해야합니다. arm32v5는 매우 오래된 아키텍쳐이며, 이 과정을 아무리 요즘 AI가 방법을 다 가르쳐준다 한들 임베디드 환경용 이미지를 직접 빌드하는 작업은 매우 진입장벽이 높아서 정말 고생할 겁니다. 작업중간에 트러블이 생겨도 이게 무슨 문제인지 이해를 못해서 진행이 안될 것이 뻔하기 때문입니다.

2026/3/21 update:
 L009모델이 가장 저렴한 모델이며 ARM64를 지원하기 시작했습니다. 따라서 container를 사용하여 tailscale을 손쉽게 구현할 수 있습니다. hEX S (2025)의 ARM64화는 아직 가망이 안보입니다..

 저도 hEX S (2025)모델이 ARM CPU모델 중 가장 저렴하여 이 모델을 구입해서 설치하려 했지만, 구입하고 나서 OS가 arm32v7 미지원(CPU하드웨어적으로는 v5/v7 양쪽 다 지원)이라서 직접 빌드해서 써야하는 상황이라는 것을 알았을 때는 이미 늦었고, 한번만 만들고 계속 쓸 수 있다면 하겠지만 container의 특징상 이걸 펌웨어 업데이트할 때마다 새로 빌드할 필요가 있었습니다. 어찌저찌 한번 빌드환경을 만들면 좋겠지만 대다수의 사람들이 그렇게까지는 못하기 때문에 고역일겁니다.

 라우터 장비에서 돌아가는 컨테이너 특성상 보안이 중요하기 때문에 공식 패키지만 사용하는 게 좋지만 arm32v5용 이미지를 누군가 따로 만들어 공개중인 비공식판을 쓰겠다면 아래 링크를 쓰면됩니다.
저같은 경우에는 ARM64 Mikrotik장비에 container, 그리고 안쓰는 구형 mips계열 실기라우터에 openwrt를 올린 후 각각 독립적인 tailnet을 구성해서 쓰고 있습니다.

seanmamasde/tailscale-mikrotik:latest-armv5

Package tailscale-mikrotik · GitHub



 3.2 사전준비 설정
 간혹 위치가 약간 틀린 경우도 있긴 하지만 기본적으로 Mikrotik의 winbox는 커맨드라인을 거의 그대로 바라보는 형식이기 때문에 "커맨드=winbox의 메뉴위치"라서 익숙해지면 직관적입니다.
  -USB메모리(SSD) 준비 : mikrotik에 USB를 꽂고 winbox에서 ext4로 포멧하는 게 가장 쉽습니다.
    /system/disks에 있습니다.

  -container용 전용 브릿지 생성 및 IP부여
    /interface/bridge add name=bridge_container
    /ip/address add address=172.24.0.1/24 interface=bridge_container
    ※Container이미지용 IP가 아닌 같은 subnet대역의 라우터측 IP 지정입니다.

  -tailscale container용 가상이더넷장치 생성 
    /interface/veth add name=veth_tailscale address=172.24.0.2/24 gateway=172.24.0.1
    /interface/bridge/port add interface=veth_tailscale bridge=bridge_container
    ※Container이미지용 IP지정입니다. /ip/address에서 지정이 아닌 가상interface생성시에 지정됩니다. /ip/address에서 직접 지정해도 되긴 합니다만 별 의미가 없고 관리가 난잡해지니 veth에서 지정해주는 것이 좋습니다. 복수IP도 지정 가능합니다.

  -tailnet에 트래픽이 나갈 수 있도록 정적 라우팅(static routing)지정
   /ip/route add dst-address=100.64.0.0/10 gateway=172.24.0.2
   tailscale의 개인네트워크 주소대역 100.64.0.0/10으로 나가는 게이트웨이를 container를 통해서 나가게끔 지정하는 설정입니다. 이 설정이 없으면 라우터 밑에 물린 단말들이 tailnet 바깥으로 통신할 수 없습니다.

  -container 앱의 기본설정
   /container/config set registry-url=https://ghcr.io tmpdir=/usb1/container/pull
  ※반드시 라우터 내부 NAND 플래시가 아닌 USB또는 외장ssd로 지정바랍니다.
  ※github가 아닌 docker로 지정하면 계정/패스워드도 필요합니다.


  -tailscale container 이미지 작성 전 상세설정1 (tailscale관리페이지 설정)
   Setting ->Keys->Generate auth key->
   description을 적당히 지정, "Pre approved"을 ON한 후 키생성을 하면 단 한번만 보여주는 키를 생성합니다. 관리자라도 정말로 한번만 보여주니까 반드시 복사해두십시요. 잃어버리면 revoke해서 비활성화 하고 다시 키생성하면 되긴 합니다. 이 키는 로그인ID와 패스워드와 같은 것이라 누구에게도 알려져서는 안됩니다.







  -tailscale container 이미지 작성 전 상세설정2 (mikrotik 라우터 설정)
   /container/mounts add list=tailscale_mount src=/usb1/container/tailscale dst=/var/lib/tailscale
   source는 이미지가 위치할 장소지정을 의미합니다. 내장 NAND는 절대 지정하지 말기 바랍니다.
   destination는 이미지 내부의 tailscale의 위치를 지정하는데, 밑의 envs(environment)옵션지정과 반드시 일치해야 합니다. TS_AUTH_KEY에 위에서 생성한 auth key값을 "tskey-auth-"를 포함해 그대로 복사합니다. 이 키가 윈도우가 아닌 장비들이 tailnet에 로그인할 때 쓰입니다.

   /container/envs add list=tailscale_envs key=TS_EXTRA_ARGS value=--accept-routes
   /container/envs add list=tailscale_envs key=TS_ROUTES value=172.24.0.0/24
   /container/envs add list=tailscale_envs key=UPDATE_TAILSCALE value=-y
   /container/envs add list=tailscale_envs key=TS_STATE_DIR value=/var/lib/tailscale
   /container/envs add list=tailscale_envs key=CONTAINER_GATEWAY value=172.24.0.1
   /container/envs add list=tailscale_envs key=TS_AUTH_KEY value=tskey-auth-(키코드)
 라우터 내부의 서브넷 접근을 혀용하기 위해 accept routes를 허용했고, VPN용도로 쓰고싶은 분들은 TS_EXTRA_ARGS에 --advertise-exit-node를 스페이스 하나 추가로 옵션지정해주면 됩니다. 
 172.24.0.0/24은 라우터의 내부 서브넷입니다. 예제로는 위의 container 브릿지용 대역만 넣었지만 이걸 넣지않고 라우터 별도 내부대역을 지정하면 그 대역 단말들을 tailnet에 접속한 모든 단말들끼리 외부에서 직접 접근이 가능해집니다. 예를들면 mikrotik의 기본대역 192.168.88.0/24을 추가해주면 라우터의 winbox를 포함한 기본설정된 내부대역을 접근할 수 있습니다. 만약 대역을 192.168.88.0으로 하겠다면 /ip/route의 정적라우팅도 잊지말고 바꿔야 합니다.

  드디어 준비가 끝났습니다. 이제 이미지 생성입니다.

  -tailscale이 설치된 container작성
  /container add name=tailscale1 remote-image=tailscale/tailscale/latest root-dir=/usb1/container/tailscale interface=veth_tailscale dns=8.8.8.8 mountlists=tailscale shm-size=64MB tmpfs=/tmp:64:01 envlists=tailscale start-on-boot=yes logging=yes 
  ※fluent-network가 제작한 이미지도 사용가능하지만 공식 tailscale과 envs옵션지정이 같은 기능이라도 약간 틀려서 혼동할 수 있으니 주의바랍니다.

 여기까지 하면 github의 tailscale공식페이지에서 각 장비에 맞는 CPU아키텍쳐의 이미지를 자동으로 다운로드 해서 생성합니다. 문제가 없다면 생성되었을 것이고 수동으로 start 해줍니다.
   /container start tailscale1  (위에서 생성한 name명을 입력)

github서버 이상 또는 라우터 펌웨어 버그나 자동 생성 이미지가 라우터와 다른 CPU아키텍쳐로 생성된 게 아니라면 정상 시작할 겁니다. 위에서 자동 approve를 했기 때문에 tailnet에 연결되었습니다.

하지만 아직 subnet 연결이 허용안되어 있으니 연결된 머신을 클릭하여 awaiting approval을 edit에서 대역을 체크해주면 이제 같은 tailnet에 접속한 모든 PC/휴대폰/서버 등에서 라우터 내부와 통신이 가능해집니다. 또한 잊지말고 각 머신의 오른쪽 "..."을 클릭해서 키가 만료되지 않도록 "Disable key expire"를 클릭해주면 키 재성성을 할 필요없이 영원히 계속 사용할 수 있습니다.






여기까지가  mikrotik에서 tailscale container를 생성하여 접속하는 방법을 설명하였습니다. 저는 현재 subnet route가 정상작동하고 있지만 처음 생성했을 당시에는 통신이 불가능했었습니다. 왜 갑자기 가능한지는 지금도 모르겠지만 잘 안된다면 스트레스 받지말고 물리적인 서브라우터를 밑에 물려서 tailscale을 별도 설치하는 게 확실한 방법입니다.

4. 결론
 물리적인 방법과 container로 mikrotik에서 tailscale을 운용하는 방법을 다뤄봤습니다. ARM32를 처음 도입했을 때 공식이미지가 존재하지 않는다는 걸 깨닫고 값싼 중고 라우터를 구해 물리 tailscale 게이트웨이를 제작해서 쓰다가 컨테이너도 도전해서 잘 돌아가서 운용중에 있습니다. wireguard보다 훨씬 운용이 편해져서 아주 만족하고 있습니다.

 굉장히 긴 글 읽느라 수고하셨습니다.