AWS國際帳號認證 AWS Client VPN 連線成功但無法存取 VPC 內部資源：路由與 DNS 排查
先理解：連上 VPN，不代表就能進 VPC
AWS Client VPN 顯示連線成功，只能證明身分驗證與隧道建立完成，真正的資料流是否能穿過去，還要看路由、授權、回程路徑、Security Group、NACL 與 DNS 解析。很多人一看到連線狀態是 Connected，就以為後面的 VPC 資源應該立刻可用，結果不是網站打不開，就是資料庫連不上，甚至連內部網域名稱都解析失敗。這類問題最怕憑感覺改設定，因為 Client VPN 的流量路徑比一般跳板機更長，只要其中一層少了一條規則，表面上看起來像是 VPN 壞了，實際上可能只是某個子網沒放行。
排查這類問題，最有效的方法不是亂試，而是先把流量分成幾個環節：客戶端是否收到正確路由，Client VPN 端點是否允許該網段，VPC 內資源所在子網是否能回到客戶端位址段，最後才是主機層與 DNS。只要照著這個順序看，通常很快就能找到卡點。
第一步：先確認你到底在測什麼
在開始改設定前，先釐清目標資源是哪一種。是私有 EC2、RDS、ECS 任務、內部 ALB，還是私有 Route 53 網域？不同資源對應的驗證方式不一樣。很多人習慣先 ping，但 ping 不通不代表服務不可用，因為許多安全規則根本沒放 ICMP。若你要驗證的是網頁服務，應該直接測 80 或 443；若是資料庫，就測 3306、5432 或實際埠號；若是內部 API，應該確認域名能不能正確解析到私網 IP。
換句話說，先用最直接的方式證明問題是路由、DNS，還是應用層服務本身。這一步看似簡單，卻能省下最多時間。因為如果連 IP 都打不到，先看路由；如果 IP 打得到但域名不行，先看 DNS；如果連線建立後馬上逾時，常常是回程路由或安全群組沒有對上來源位址段。
第二步：檢查 Client VPN 的路由是否真的下發到客戶端
Client VPN 的核心是把你本機的流量導進 AWS。這件事成立的前提，是端點上已經建立對應的 route。很多人只做了連線驗證，卻忘了在 Client VPN endpoint 裡新增目標網段，例如 VPC CIDR 或特定子網 CIDR。若這條路由沒有存在，客戶端即使顯示已連線，也不會把目的地為內網的封包送進 VPN。
如果你啟用的是 split tunnel，這個問題更常見。Split tunnel 的意思是只有被宣告的網段才會走 VPN，其餘流量仍經由本機網路出去。也就是說，端點上沒有明確下發的 CIDR，本機路由表就不會出現對應路徑。你可以在客戶端查看路由表，確認是否真的存在指向 VPN 虛擬介面的路由。
- Windows 可用
route print檢查路由表。 - macOS 或 Linux 可用
netstat -rn或ip route檢查。 - 若目的網段根本不在路由表裡，問題幾乎可以直接鎖定在 Client VPN route 設定。
AWS國際帳號認證 這裡還有一個常見誤解：有些人只把 VPC 的某個子網加進路由，卻忽略實際資源可能在另一個子網。若資源分布在多個私有子網，最好直接以 VPC CIDR 覆蓋，或逐一列出必要網段，避免漏配。
第三步：確認 Authorization rules 有沒有放行
路由存在，不代表使用者可以進。AWS Client VPN 還有一層 Authorization rules，這層是在控制哪個使用者或群組可以存取哪個目的網段。這是最容易被忽略的地方之一。很多人以為新增 route 就夠了，結果流量已經進到 VPN，卻因為沒有授權，被端點直接擋下。
排查時要確認三件事：第一，授權規則的 destination CIDR 是否涵蓋你的目標資源；第二，授權是否套用到正確的使用者或群組；第三，若你使用的是 AD 或 SAML 整合，群組名稱是否與規則匹配。只要其中一項錯了，就會出現連線成功但無法存取的情況。
實務上，先用較大的網段做測試，例如整個 VPC CIDR。若這樣可以通，再往下縮到更精細的子網或資源網段。這樣做不是偷懶，而是先把問題切成兩段：先驗證路徑成立，再做最小權限收斂。若一開始就把規則切得太細，查問題時反而很難看出是哪一段沒放行。
第四步：檢查 VPC 子網的回程路由
很多人把注意力放在 VPN 端點，卻忽略 VPC 內資源能不能回得來。網路不是單向通行，封包要進得去，也要回得來。當 Client VPN 把你的來源位址改成 client CIDR 後，VPC 內的資源如果不知道這個網段該往哪裡送回應，連線就會卡在握手階段，表現出來通常是逾時，而不是明確拒絕。
因此，除了 Client VPN route 與授權規則，還要看 VPC 內資源所在子網的 route table。回程路由若不完整，會出現很典型的症狀：ICMP 可能偶爾有反應，但 TCP 連線一直不穩；某些服務能開頁面，某些服務卻完全打不開；同一台機器從同一個 VPN 連線，有時可達，有時不可達。
若你的資源在多個私有子網，或經過內部負載平衡器，務必要確認該路徑上的所有子網都能理解 client CIDR 的去向。跨子網、跨路由表、跨帳號或跨 VPC 的情境下，回程路由缺失是最常見的隱性問題。
第五步：Security Group 與 NACL 不要只看入站
就算路由完全正確，安全控制也可能把封包擋掉。Security Group 通常是第一個要看的主機層設定。對私有 EC2、RDS 或內部服務來說，入站規則必須允許來自 Client VPN client CIDR 的流量，而不是只允許 VPC 內部某個固定位址。很多人誤以為因為流量是從 AWS 內部來的，所以可以直接放行，事實並不是如此。
NACL 也不能忽略。Security Group 是有狀態的，但 NACL 是無狀態的，入站放了還要看回程埠是否允許。若你只打開服務埠，卻把 ephemeral port 擋掉，會出現建立連線後立刻失敗的現象。對於資料庫、內部 API 或跨多埠服務，NACL 的誤配置尤其容易造成誤判。
- AWS國際帳號認證 確認資源所在 Security Group 是否允許 Client CIDR。
- 確認 NACL 的入站與出站都沒有擋住必要埠與回程埠。
- 若使用內部負載平衡器，還要看後端目標群組的安全規則是否一致。
這一層的排查原則很簡單：若路由正確但 TCP 仍逾時，先看 Security Group；若單一埠能通，另一個埠不通，再看 NACL 或應用服務本身。
第六步：DNS 問題常讓人以為是網路壞掉
如果你只能用 IP 存取，無法用內部網域名稱存取，問題多半在 DNS。AWS Client VPN 支援下發 DNS 設定，但前提是你有正確配置 endpoint 的 DNS server。若內部網域是私有 Route 53 hosted zone，或使用企業內部 DNS，客戶端必須把查詢送到能解析內網名稱的伺服器，否則名字會一直解析到公開 IP，甚至直接找不到紀錄。
常見做法有兩種：一種是使用 VPC 內可解析私有網域的 DNS，例如 VPC 預設解析器；另一種是透過 Route 53 Resolver inbound endpoint，讓 Client VPN 客戶端把解析請求送進來。重點不在用哪一種，而在於客戶端實際拿到的是哪個 DNS，且這個 DNS 是否真的能看到你的內部記錄。
排查時不要只看瀏覽器結果，應該直接在終端機做解析測試。
- Windows 可用
nslookup 內部網域 DNS伺服器IP。 - macOS 或 Linux 可用
dig 內部網域 @DNS伺服器IP。 - 若解析到錯誤位址，先別急著改服務，先修 DNS。
另外，若你改過 DNS 設定，但客戶端仍然解析到舊結果，記得清快取。Windows 可以執行 ipconfig /flushdns，macOS 與 Linux 也要依實際環境清除系統或瀏覽器快取。很多看似莫名其妙的故障，其實只是舊 DNS 記錄還留在本機。
第七步：從客戶端角度驗證，別只看 AWS 控制台
AWS 控制台只顯示設定，真正發生什麼事，要回到客戶端看。你可以先確認 VPN 介面有沒有拿到目標網段的路由，再測試目標 IP 是否可達。若連 IP 都不通，就不用浪費時間查域名。若 IP 通、域名不通，就集中火力查 DNS。若某些網段通、某些網段不通，就回頭看 route 與 Authorization rules 是否有漏網段。
建議的測試順序如下。
- 查看本機路由表，確認目的 CIDR 是否走 VPN。
- 對目標 IP 做連通性測試，例如
ping或更實際的 TCP 測試。 - 對目標埠做連線測試，例如
nc -vz 10.0.1.10 443或telnet 10.0.1.10 443。 - 對內部網域做解析測試，確認解析器是否正確。
- 必要時觀察封包是否有到達目標主機，例如從日誌或流量監控判斷。
AWS國際帳號認證 如果你有權限看 VPC Flow Logs，那會非常有幫助。Flow Logs 能告訴你封包到底是被接受還是拒絕，也能幫你分辨是 SG、NACL 還是路由的問題。當你看到封包根本沒到目標主機，就應該回去看前面的路由與授權；若封包到了卻被拒絕，才是安全規則的問題。
第八步：幾個最常見的錯誤組合
只建好 endpoint，沒加 route
這是最基本也最常見的錯。VPN 連上了，但客戶端根本沒拿到目的網段，所有流量都留在本機。
有 route，沒授權
這種情況最迷惑，因為你會看到配置似乎都對，卻始終打不通。實際上是 Authorization rules 沒放行。
能用 IP，不能用名稱
幾乎就是 DNS 沒配好，或客戶端沒有使用可解析私有網域的 DNS。
單一服務不通，其他都正常
通常是 Security Group、NACL，或目標服務本身的監聽埠問題，不一定是 VPN 故障。
有時通有時不通
優先懷疑回程路由、跨子網路由表、負載平衡器後端設定，或 DNS 快取造成的路徑不一致。
第九步：建議的排查順序
若你現在就是遇到連線成功但無法存取，建議照下面順序查，效率最高。
- 先確認客戶端路由表是否有目標 CIDR。
- 再確認 Client VPN endpoint 是否有對應 route 與 Authorization rules。
- 接著看 VPC 內資源所在子網的回程路由。
- 然後檢查 Security Group 與 NACL 是否允許 client CIDR 與必要埠。
- 最後才查 DNS、快取與應用服務本身。
這個順序的好處是，前面幾層出錯時，後面層根本不用看。反過來說，如果你一開始就去改 DNS 或重啟服務，通常只會讓問題更模糊。網路排查最怕的是跳步驟，因為每一層都可能表現成同一種症狀：連得上 VPN，但進不了內網。
第十步：把設定固定成可維護的樣子
真正穩定的做法，不是每次出問題再救火，而是把 Client VPN 的路由、授權、DNS 與子網路由表整理成一份清楚的對照表。至少要記錄三件事：Client CIDR 是多少、VPC CIDR 是多少、內部網域要透過哪個 DNS 解析。再加上資源所在子網與對應 Security Group，之後不管是擴網段、加服務、換子網，維運人員都能立刻知道哪一層要同步調整。
AWS國際帳號認證 如果團隊裡有人常常接手不同專案，這份整理尤其重要。因為 Client VPN 的問題往往不是單點失誤，而是多個小設定累積後剛好撞在一起。今天新增一個子網，明天換一個 DNS，後天又把 Security Group 收緊，最後表面上像是同一個故障，實際上卻有好幾個根因。把規則固定下來，後續才不會每次都從零開始猜。
結語：先看路由，再看授權，最後才是 DNS
AWS Client VPN 連線成功但無法存取 VPC 內部資源，八成不是單一元件壞掉，而是設定鏈條中的某一環沒接上。最有效的思路，是先看路由是否下發，再看授權有沒有放行，接著檢查回程路由與安全群組，最後處理 DNS 與客戶端快取。只要你能把這幾層分開驗證，很多看起來很玄的問題，其實都能很快定位。
記住一句話：VPN 連上，只代表隧道開了；資源可達，才代表整條路真的通了。兩者不是同一件事。把這個觀念抓穩，之後再碰到類似狀況，你就不會再被表面的 Connected 騙過去。
