LAN phía sau một phiên AWS Client VPN: những gì được chuyển tiếp

Máy tính xách tay kết nối tới điểm cuối AWS Client VPN, đến được mạng con riêng, và mọi thứ trông khỏe mạnh. Máy để bàn trên cùng LAN không đến được gì, dù máy chủ Linux cũng có giao diện cầu và cả hai máy nằm trên cùng một sợi cáp. Không có gì cấu hình sai trong đường hầm; phần còn thiếu là định tuyến, và cây cầu chỉ là manh mối đánh lạc hướng.

Mở rộng một phiên Client VPN ra LAN là vai trò cổng. Đó không phải một đoạn Ethernet kéo dài vào trong dịch vụ được quản lý.

Máy chủ hoạt động còn LAN thì không

Giao diện đường hầm trên máy Linux có địa chỉ trong CIDR của ứng dụng khách Client VPN, và điểm cuối đã đẩy các tuyến cho dải VPC. Yêu cầu thực hiện trên máy đó là lưu lượng sinh ra tại chỗ: nó chọn tuyến, đi ra qua đường hầm và nhận trả lời. Đường đi đó không bao giờ chạm vào mã chuyển tiếp, giao diện LAN hay bất kỳ quy tắc tường lửa nào điều khiển lưu lượng đi qua.

Lưu lượng từ một thiết bị LAN khác là một luồng khác. Nó đến giao diện LAN, cần một tuyến trỏ vào đường hầm, cần bật chuyển tiếp, cần tường lửa cho phép, và cần gói trả lời quay về qua đúng máy chủ đó. Bốn điều kiện, và bài kiểm tra trên máy xách tay đang chạy không chứng minh được điều nào. Từ máy để bàn, lỗi trông lạ lùng: đường hầm đang lên, thông tin đăng nhập hợp lệ, và đích đến đơn giản là không bao giờ trả lời. Khiếm khuyết nằm tại chỗ trong đường chuyển tiếp của cổng, không phải ở dịch vụ.

Không phải ứng dụng khách nào cũng làm được cổng

AWS nêu rõ ứng dụng để bàn Client VPN của họ không hỗ trợ chuyển tiếp IP, và các ứng dụng khác có thể có. Ràng buộc đó quyết định kiến trúc trước khi bất kỳ lệnh nào được gõ. Nếu ứng dụng duy nhất có sẵn là ứng dụng để bàn chính thức, một cổng Linux chuyển tiếp cho LAN không phải cấu hình bạn có thể hoàn thành, và không lượng masquerading nào thay đổi được điều đó.

Ứng dụng thay thế cũng phải khớp với phương thức xác thực của điểm cuối và chính sách bạn định áp dụng. Các điểm cuối dựa trên chứng chỉ, thư mục và SAML không chấp nhận cùng cấu hình khách, và một ứng dụng bên thứ ba xác thực được nhưng bỏ qua các tuyến được đẩy vào không phải là cải tiến.

Hãy coi việc chọn ứng dụng khách là một phần của buổi rà soát thiết kế. Nó quyết định mô hình chuyển tiếp LAN có khả dụng hay không, và quyết định điểm cuối nhìn thấy danh tính nào cho từng thiết bị phía sau cổng. Ghi lại ứng dụng khách và cấu hình điểm cuối đã dùng để kiểm thử. Một lần đổi ứng dụng sau sáu tháng có thể âm thầm bỏ đi năng lực mà thiết kế đã giả định.

Dẫn LAN vào đường hầm và dịch địa chỉ

Khi đã có ứng dụng được hỗ trợ, phần còn lại là công việc cổng thông thường. Các thiết bị LAN cần một tuyến cho dải VPC trỏ tới máy chủ Linux, và máy chủ cần bật chuyển tiếp. Nếu muốn VPC nhìn lưu lượng như chính ứng dụng khách đang kết nối chứ không phải một địa chỉ LAN tùy tiện, hãy dịch địa chỉ nguồn khi đi ra.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Giới hạn quy tắc trong giao diện đường hầm và dải VPC, như trên, thay vì masquerading mọi thứ máy chủ chuyển tiếp. Quy tắc hẹp hơn dễ suy luận hơn, và nó không âm thầm thay đổi lưu lượng lẽ ra phải giữ nguyên địa chỉ nguồn gốc.

Hãy để tuyến LAN tự đến nếu có thể: một tùy chọn DHCP, một thông báo định tuyến hoặc một tuyến tĩnh do thứ quản lý LAN đẩy xuống. Một tuyến chỉ tồn tại trên một máy kiểm thử sẽ khiến thiết kế trông hỏng ngay khi người khác thử nó.

Gói trả lời cũng cần một đường về

Khi yêu cầu đến được VPC, gói trả lời phải quay về qua đúng các trạng thái dịch địa chỉ và tìm được tuyến LAN trên cổng. Phần đó thường hoạt động khi quy tắc masquerade có mặt, vì bảng ánh xạ sống trên chính máy chủ đã thực hiện nó. Nó hỏng khi phía VPC có một tuyến gửi trả lời đi nơi khác, và đó là lý do cả tuyến CIDR của khách lẫn liên kết mạng con trên điểm cuối đều quan trọng.

Hãy xem bộ đếm, không chỉ ping. Một quy tắc masquerade không có gói nào cho bạn biết yêu cầu chưa bao giờ đến giao diện đường hầm, điều này chỉ ngược về tuyến LAN hoặc bảng định tuyến của chính ứng dụng khách. Một quy tắc có gói nhưng không có trả lời chỉ về phía VPC, các quy tắc cấp quyền hoặc một nhóm bảo mật không chấp nhận địa chỉ nguồn đã dịch. Hãy đọc cả hai chiều trước khi thay đổi bất cứ điều gì, vì con số chỉ tăng ở một phía là đường một chiều chứ không phải đường chậm.

Hãy nhớ điểm cuối là dịch vụ được quản lý. Không có tệp cấu hình máy chủ để sửa và không có chỉ thị client-config để thêm, nên những hướng dẫn viết cho máy chủ OpenVPN tự quản lý với tuyến mạng con khách tùy chỉnh không chuyển sang được. Trên AWS, các đòn bẩy là liên kết mạng con, quy tắc cấp quyền và bảng định tuyến của VPC.

Danh tính dùng chung là phần mà chính sách phải trả lời

Mọi thiết bị phía sau cổng đều dùng phiên VPN của cổng. Các quy tắc cấp quyền của điểm cuối cho phép một người dùng hoặc một nhóm, và theo góc nhìn của dịch vụ chỉ có đúng một người dùng trên phiên đó. Chuyển tiếp cục bộ không nhân danh tính đó thành xác thực cho từng thiết bị, và không mở rộng kiểm tra tình trạng thiết bị tới chiếc máy in trong góc.

Điều đó có thể chấp nhận được, hoặc có thể là lý do thiết kế bị từ chối. Nó phụ thuộc vào việc tài nguyên VPC giả định gì về người đang gọi. Một danh tính dùng chung khớp với mô hình cấp quyền thì ổn; một danh tính âm thầm biến một phiên đã xác thực thành quyền truy cập toàn LAN là một phát hiện đang chờ được ghi lại.

Nếu yêu cầu thực sự là nối cả một địa điểm vào VPC, hãy so sánh một thiết kế site-to-site được hỗ trợ trước khi mở rộng ứng dụng khách truy cập từ xa. Ngữ nghĩa khác nhau, và một phiên khách đã qua NAT là phương án thay thế tồi cho liên kết địa điểm khi VPC cần khởi tạo kết nối vào LAN.

Hãy quyết định ứng dụng khách, tuyến, phần dịch địa chỉ và câu chuyện danh tính theo đúng thứ tự đó. Mỗi thứ ràng buộc thứ tiếp theo, và thứ tự giải thích vì sao máy chủ chạy được còn LAN thì không.