macOS 拿掉 L2TP 之後：在 Docker 裡自建 VPN 通道跑爬蟲

「這個系統只能從內網進去看，應該沒辦法自動化吧？」

這是我們接案時很常聽到的一句話。這篇文章用一個實際案子告訴你：可以，而且連作業系統扯後腿的時候都可以。

場景：33 家分店的資料，鎖在各自的內網裡

客戶是一家連鎖牙醫集團。各分店的健保申報狀態——是否準時送件、是否退件、點數是否異常——只存在各店本地的 HIS 醫療系統裡。

總部要看，流程是這樣的：逐店撥 VPN 連進內網、登入 HIS、人工翻頁抄數字。30 幾家店每月巡一輪，總部形同沒有即時視野。

然後事情變得更糟：新版 macOS 移除了內建的 L2TP/IPSec VPN 支援。這些分店的 NAS 走的正是 L2TP——也就是說，連「人工連進去」這條路都快斷了。

第一個決策：為什麼不改 33 台 NAS 的 VPN 協定

最「乾淨」的解法聽起來是：把 33 家分店的 VPN 全部升級成新協定。

我們沒有這樣做，理由很實際：

• 改動面太大：33 台分散在各地的既有設備，每一台都要動，等於 33 次可能出錯的現場作業。
• 風險不對稱：VPN 是各分店日常營運在用的通道，改壞一台，影響的是那家店的正常作業——為了報表自動化去動營運命脈，划不來。
• 老系統的鐵律：能不動客戶既有環境，就不動。自動化方案應該去適應現場，而不是要求現場配合方案。

不能改的老系統、鎖在內網後面的資料，一樣有解——解法是讓自動化去遷就環境，而不是反過來。

解法：把整條 VPN 通道搬進 Docker 容器

作業系統不支援 L2TP？那就不要依賴作業系統。

我們在 Docker 容器裡自建了完整的 L2TP/IPSec 通道：strongSwan 負責 IPSec 加密層，xl2tpd 負責 L2TP 隧道層。容器自己就是一個完整的 VPN 客戶端，宿主機的 macOS 有沒有內建支援，完全無關。

要讓容器有能力建立 VPN 通道，需要放開幾個權限：

docker run --privileged \
  --cap-add=NET_ADMIN \
  --device=/dev/net/tun \
  ...

• --privileged 與 NET_ADMIN：讓容器能操作網路介面與路由表。
• /dev/net/tun：VPN 隧道裝置，建立虛擬網路介面的必要條件。

這樣一來，33 家分店的 NAS 一台都不用動——它們眼中連進來的，就是一個普通的 L2TP 客戶端。

容器裡的第二層：Playwright 控瀏覽器抓老系統

通道打通只是一半。HIS 是典型的 legacy 網頁系統，沒有 API 可以呼叫，資料只存在登入後的頁面表格裡。

所以容器內還跑了第二層：Playwright 驅動 Chromium，自動完成登入、導頁、抓取「申報上傳總明細」表格的完整流程。對 HIS 來說，這就是一個正常的使用者在操作瀏覽器——只是這個使用者不會累、不會抄錯數字。

序列執行的取捨：為什麼不平行跑

工程師的直覺是：33 家店，開 33 條連線平行抓，不是快很多？

實務上我們選擇序列執行——一次撥一條 VPN、抓完一家、斷線、換下一家。因為 L2TP 通道一次只能穩定維持一條，硬要平行只會換來難以除錯的連線衝突。

實測節奏是：

• 每家分店約 30–60 秒
• 33 家全程約 15–30 分鐘
• 結果集中寫入雲端資料庫（Supabase）

每月跑一輪的場景下，15–30 分鐘和 2 分鐘沒有實質差別——但穩定性的差別是天與地。自動化系統的第一美德是穩定，不是快。

成果：總部第一次「一眼看完」

排程每月自動執行後，總部打開儀表板，就能看到全部分店的申報狀態與異常——這是這家集團第一次擁有這個視野。原本每月人工逐店巡檢的工作，整條退役。

這個案子的完整脈絡（包括它和週報自動化、財務儀表板怎麼串成同一套數據地基），可以在案例研究裡看到。

你的「不可能自動化」，可能只是還沒遇到對的解法

很多企業把「系統太老」「只能內網連」當成自動化的死刑判決。這個案子想說的是：那只是工程上的邊界條件，不是終點。

如果你的公司也有一段「每個月都要人工連進某個老系統抄資料」的流程，歡迎聊聊——你描述現在的流程，我們告訴你哪一段最值得先自動化、大概怎麼做。

預約 30 分鐘免費流程診斷 →