# PrivateLink hay VPN site-to-site: chọn đường mạng riêng tới hạ tầng khách hàng

> Câu đầu tiên nên hỏi đội mạng của khách hàng là ai cần gọi vào ai. Chuyện mã hóa để sau.

Bản gốc: https://fdetimes.net/vi/bach-khoa/privatelink-vpn-site-to-site-ket-noi-mang-rieng-toi-ha-tang-khach/

Buổi kickoff thứ hai, trưởng bộ phận bảo mật bên khách hàng nói thẳng: hệ thống của họ không có IP công khai nào và sẽ không bao giờ có. Dịch vụ của bạn chạy trong VPC của công ty bạn, còn dữ liệu nằm trong mạng của khách. Đến lúc này bạn mới phát hiện cả hai bên đều dùng dải 10.0.0.0/16.

Chọn kiểu kết nối lúc này sẽ quyết định mọi việc phía sau: ai phải cấu hình gì, đội nào phải xếp lịch, và có phải đụng tới sơ đồ địa chỉ mạng hay không. Phần lớn lựa chọn xoay quanh hai cách: PrivateLink (trên Azure gọi là Private Link) và VPN site-to-site.

Cả hai đều giữ lưu lượng khỏi Internet công cộng, nhưng giải hai bài toán khác nhau. Một FDE cần biết nên đề xuất cách nào trước khi đội mạng của khách hàng lên tiếng hỏi.

## Công bố một dịch vụ hay nối hai mạng?

Cách nghĩ dễ nhớ nhất là thế này: PrivateLink đưa một dịch vụ vào mạng của người dùng, còn VPN nối hai mạng lại với nhau.

Theo tài liệu của AWS, PrivateLink cho VPC truy cập một dịch vụ như thể dịch vụ đó nằm ngay trong VPC, không cần internet gateway, NAT, IP công khai, Direct Connect hay Site-to-Site VPN.

Bên dùng (consumer) chủ động tạo kết nối, bên cung cấp (provider) chấp nhận hoặc từ chối. Lưu lượng giữa VPC endpoint và endpoint service đi trong mạng AWS, không ra Internet công cộng.

VPN site-to-site thì khác hẳn. Đây là kết nối IPsec, mỗi kết nối có hai tunnel mã hóa, dùng song song được để tăng độ sẵn sàng. Vì hai mạng được nối với nhau, AWS khuyến nghị dùng các dải CIDR không chồng lấn khi nối nhiều VPC về một mạng on-premises chung.

**Điểm mấu chốt:** Trước khi chọn công nghệ, hãy hỏi ai cần gọi vào ai.

## Thử với một ca cụ thể: hai VPC cùng dải 10.0.0.0/16

Thử hình dung: bạn là FDE của một công ty cung cấp API suy luận mô hình. Ứng dụng của khách chạy trên AWS và cần gọi vào API của bạn.

Cả hai VPC đều là 10.0.0.0/16. Với VPN site-to-site trên AWS hay VNet peering trên Azure, nhà cung cấp đều khuyên hoặc đòi hỏi dải địa chỉ không chồng lấn. Vì thế một trong hai bên thường phải đánh lại địa chỉ mạng, và việc đó rất dễ phình thành một dự án riêng nằm ngoài phạm vi deployment của bạn.

PrivateLink tránh được chuyện này. AWS nói rõ đây là giải pháp phù hợp khi các VPC trùng dải IP, và blog mạng của AWS cho biết bạn công bố được endpoint giữa các VPC trùng dải mà không phải đổi sơ đồ địa chỉ bên dưới.

Lý do là interface endpoint nằm ngay trong subnet của khách và nhận IP thuộc dải của khách, nên không có tuyến nào bị đụng nhau.

Khi làm thật, thứ tự thao tác như sau. Phía bạn, tức provider, đặt một load balancer trước dịch vụ rồi tạo endpoint service từ load balancer đó.

Mặc định endpoint service chưa mở cho ai, nên bạn phải thêm quyền cho đúng AWS principal của khách, thường là tài khoản AWS của họ. Phía khách tạo interface endpoint trong subnet của mình, sau đó bạn chấp nhận yêu cầu kết nối.

Bước cuối thuộc về khách và là bước đội bảo mật thích nhất. Endpoint nằm trong subnet của họ nên họ kiểm soát truy cập bằng security group của chính mình. Chẳng hạn họ chỉ cho các máy chủ ứng dụng gọi vào cổng 443 của endpoint. Họ không phải mở gì ra ngoài, và cũng không phải tin vào một tuyến mạng rộng tới VPC của bạn.

## Khi bạn cần gọi vào mạng của khách

Giờ đảo chiều lại. Agent của bạn phải đọc một cơ sở dữ liệu nằm trong trung tâm dữ liệu on-premises của khách. Mô hình "consumer mở kết nối" của PrivateLink không tự động cho chiều ngược lại. Có một endpoint không có nghĩa là hai mạng đã thông nhau.

Vẫn còn một vài lối đi. AWS cho biết provider có thể chạy dịch vụ trên máy chủ on-premises, và resource endpoint cho phép truy cập cả tài nguyên trong môi trường on-premises, nên PrivateLink vẫn đáng xét khi hạ tầng khách không nằm trên AWS.

Nhưng khi bài toán thực chất là "hai mạng cần nói chuyện với nhau", VPN site-to-site thường là đáp án tự nhiên hơn. Cái giá đi kèm thì bạn nên nói rõ ngay từ đầu.

Cái giá đầu tiên là con người. Khách phải tự cấu hình thiết bị VPN của họ (customer gateway device), và mặc định chính thiết bị này phải sinh lưu lượng và khởi tạo đàm phán IKE để dựng tunnel. Ngày go-live của bạn vì thế phụ thuộc vào lịch của đội mạng bên khách.

Đừng nhầm chữ "khởi tạo" ở đây với chữ "mở kết nối" của PrivateLink. IKE chỉ là bước dựng tunnel.

Kế đến là địa chỉ. Ca trùng 10.0.0.0/16 ở trên sẽ thành vấn đề thật, vì AWS khuyên dùng các dải không chồng lấn.

Cuối cùng là băng thông. Một tunnel tiêu chuẩn đạt 1,25 Gbps. Tunnel băng thông lớn tới 5 Gbps chỉ có khi đi qua Transit Gateway hoặc Cloud WAN. Nếu agent của bạn cần đồng bộ khối dữ liệu lớn hằng đêm, hãy tính trước con số này.

## Trên Azure, logic vẫn giữ nguyên

Khách dùng Azure thì từ vựng đổi nhưng tư duy giữ nguyên. Microsoft cho biết với Azure Private Link, lưu lượng giữa virtual network và dịch vụ đi trên backbone của Microsoft, và dịch vụ không cần phơi ra Internet công cộng. Bên cung cấp có thể tạo một Private Link service để giao cho khách.

Có một chi tiết nên đem ra khi nói chuyện với đội bảo mật: private endpoint ánh xạ tới một instance tài nguyên cụ thể chứ không tới cả dịch vụ, nhờ vậy giảm rủi ro rò rỉ dữ liệu.

Mạng on-premises vẫn vào được qua ExpressRoute hoặc VPN tunnel. Microsoft cũng giới thiệu Private Link như một cách thay cho VNet peering, vốn đòi không gian địa chỉ không chồng lấn. Đây vẫn là bài toán trùng dải IP như trên AWS.

## Tự làm: năm câu hỏi cho buổi discovery

Trước khi viết dòng Terraform đầu tiên, hãy lấy được năm câu trả lời. Câu một: ai cần gọi vào ai, khách gọi vào bạn hay bạn gọi vào khách? Câu hai: dữ liệu nằm ở đâu, trên AWS, Azure hay on-premises? Câu ba: dải CIDR của từng mạng là gì, có trùng nhau không?

Câu bốn: khối lượng dữ liệu cao nhất mỗi giờ là bao nhiêu, có vượt 1,25 Gbps một tunnel không? Câu năm: ai bên khách sở hữu thiết bị mạng, và họ cần bao lâu để lên lịch cấu hình? Nếu câu một là "khách gọi vào bạn" và câu ba là "trùng", gần như chắc chắn bạn sẽ đề xuất PrivateLink.

## Những lỗi khiến deployment đứng hình

Lỗi phổ biến nhất là coi PrivateLink như một đường ống hai chiều. Nó được thiết kế để consumer gọi vào provider. Nếu agent của bạn cần chủ động gọi ngược lại, hãy thiết kế riêng cho chiều đó.

Cũng rất hay gặp là quên rằng endpoint service mặc định không mở cho ai. Khách tạo endpoint xong, báo lỗi, và hai bên mất một buổi chiều mới nhận ra chưa ai cấp quyền cho principal của họ.

Với VPN, có người chỉ dựng một tunnel trong khi mỗi kết nối có sẵn hai tunnel, rồi bất ngờ khi tunnel đó rớt. Có người hẹn ngày go-live mà chưa xác nhận đội mạng bên khách đã sẵn sàng khởi tạo IKE.

## Kỹ năng này nằm ở đâu trong hồ sơ của bạn?

Khi đọc mô tả tuyển dụng FDE, hãy để ý những cụm như "customer VPC", "private networking" hay "on-prem deployment". Nếu chúng xuất hiện, nhiều khả năng vị trí đó cần người làm được đúng phần việc này.

Trên CV, thay vì ghi "biết AWS networking", hãy viết một câu có ràng buộc và kết quả, ví dụ: đưa dịch vụ vào VPC trùng dải IP của khách bằng PrivateLink, không phải đánh lại địa chỉ mạng.

Trong phỏng vấn, đừng dừng ở định nghĩa. Hãy kể theo thứ tự bạn đã hỏi gì, chọn gì, và vì sao không chọn cách còn lại. Khách hàng ít khi nhớ bạn dùng giao thức gì. Họ nhớ việc đội bảo mật của họ không phải mở thêm một cổng nào ra Internet.

**Thử ngay tuần này:**

- Vẽ sơ đồ mạng cho một dự án đang làm: ghi dải CIDR của từng VPC, mũi tên chỉ chiều gọi, và nơi dữ liệu đang nằm
- Dựng thử trên tài khoản sandbox: một endpoint service đặt sau load balancer, cấp quyền cho một tài khoản AWS thứ hai, tạo interface endpoint ở tài khoản đó rồi gọi thử qua endpoint
- Thêm năm câu hỏi discovery về mạng vào checklist kickoff của bạn

## Nguồn

- [What is AWS PrivateLink?](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)

- [AWS PrivateLink concepts](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)

- [AWS PrivateLink - Amazon VPC Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-privatelink.html)

- [What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)

- [How AWS Site-to-Site VPN works](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html)

- [What is Azure Private Link? | Microsoft Learn](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview)

- [Announcing Azure Private Link](https://azure.microsoft.com/en-us/blog/announcing-azure-private-link/)

- [Connecting Networks with Overlapping IP Ranges](https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-networks-with-overlapping-ip-ranges/)