Vì sao VPN TAP dùng chung vẫn cần HTTPS trên cổng thông tin
VPN TAP xác thực đối tác, không xác thực dịch vụ phía sau nó. Giữ kiểm tra tên máy chủ trên cổng và cô lập những hàng xóm bạn không tin.
Hai thiết bị có thông tin đăng nhập VPN hợp lệ và dùng chung một phân đoạn Ethernet được bắc cầu. Chỉ một trong số chúng phải trả lời cho cổng thông tin văn phòng, và cái còn lại vẫn có thể yêu sách địa chỉ cổng trên phân đoạn đó. Đường hầm đã làm đúng việc của nó: nó xác thực cả hai đối tác và mã hóa mọi đường tới máy chủ. Điều nó không làm là chứng thực ai trong số họ sở hữu một tên dịch vụ, và chính khoảng trống đó là lý do cổng vẫn cần chứng chỉ hợp lệ.
VPN thực sự xác thực điều gì
Bắt tay VPN trả lời một câu hỏi: đối tác nào đã hoàn tất đường hầm này, với vật liệu khóa nào. Câu trả lời đó là theo từng đối tác và từng kết nối, và nó không nói gì về các dịch vụ mà đối tác đó công bố sau đó. Trên phân đoạn TAP, đối tác thậm chí không phải một địa chỉ duy nhất, vì nó có thể trình bày bất kỳ MAC nào và bất kỳ IP nào mà cầu sẵn sàng học. Xác thực dừng ở điểm cuối đường hầm, không dừng ở ứng dụng.
Tách ba câu hỏi thay vì gộp chúng thành một. Mỗi câu có cơ chế riêng và cách thất bại riêng.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Một triển khai có thể có đường hầm được xác thực hoàn hảo và một dịch vụ hoàn toàn chưa được xác thực phía sau. Nó cũng có thể có chứng chỉ đã được xác thực trên một máy chủ mà địa chỉ lớp hai bị đối tác khác yêu sách, và đó là lý do cả hai biện pháp kiểm soát đều thuộc về thiết kế chứ không phải cái này thay thế cái kia. Bảng là toàn bộ lập luận trong ba hàng.
ARP trên phân đoạn dùng chung không phải danh bạ
ARP ánh xạ địa chỉ IPv4 sang MAC trên liên kết cục bộ và chấp nhận câu trả lời từ bất kỳ ai trên liên kết đó. Trên phân đoạn bắc cầu dễ dãi, một đối tác có thể yêu sách địa chỉ thuộc về thiết bị khác, và cầu chuyển tiếp khung tới người trả lời gần nhất. Mã hóa mọi đường của khách hàng tới máy chủ không thay đổi điều đó, vì khung được giải mã trước khi tới cầu. Ranh giới tin cậy của ARP là phân đoạn, không phải đường hầm.
Hãy xem máy chủ thực sự học được gì: ip neigh show liệt kê các ánh xạ hiện tại và trạng thái của chúng, và một mục chuyển đổi giữa hai địa chỉ MAC trong hoạt động bình thường là triệu chứng đáng điều tra chứ không phải bỏ qua. Trên một phân đoạn nhỏ khỏe mạnh, những mục như vậy vẫn ổn định trong thời gian dài.
Cô lập đối tác và chính sách cầu tồn tại đúng cho trường hợp này. Thiết kế định tuyến thường là câu trả lời tốt hơn khi dịch vụ chỉ là IP và các thiết bị không có lý do gì để thấy khung của nhau.
Giữ kiểm tra chứng chỉ ở nơi có dịch vụ
TLS của ứng dụng trả lời câu hỏi mà đường hầm không thể: đây có phải dịch vụ tôi muốn tiếp cận không. Trình duyệt kiểm tra tên máy chủ với chứng chỉ, và lần kiểm tra đó là phần duy nhất của chuỗi gọi tên cổng thông tin thay vì đối tác.
Xem xét những gì máy chủ trình bày trước khi kết luận cảnh báo chỉ là hình thức. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal in ra chuỗi và các tên thay thế của chủ thể. Nếu tên bạn nhập không có trong danh sách đó, cảnh báo là đúng và chứng chỉ là thứ cần sửa. Dạy người dùng bỏ qua nó biến một biện pháp kiểm soát đang hoạt động thành đồ trang trí.
Hướng dẫn bắc cầu của OpenVPN mô tả mô hình Ethernet và các tùy chọn chính sách xung quanh, và đó là tài liệu tham chiếu đúng cho những gì phân đoạn nên cho phép. Hãy đọc nó trước khi nới lỏng một quy tắc cầu, vì mô hình nó mô tả là điều mà mọi kiểm tra ở trên giả định.
Quyết định xem các đối tác đó có nên dùng chung một phân đoạn hay không
Cách sửa rẻ nhất thường là ngừng chia sẻ lớp hai khi yêu cầu chỉ là khả năng tiếp cận IP. VPN định tuyến cấp cho mỗi khách hàng địa chỉ riêng, loại bỏ miền quảng bá dùng chung và biến lưu lượng giữa các đối tác thành quyết định chính sách thay vì mặc định. Khi đó cổng chỉ có một địa chỉ để bảo vệ và không có hàng xóm nào có thể yêu sách nó.
Nếu phân đoạn phải giữ lại, hãy kiểm tra cài đặt phía máy chủ cho phép các khách hàng tiếp cận nhau: grep -n client-to-client /etc/openvpn/server.conf. Khi tắt, lưu lượng khách hàng đi qua máy chủ và có thể lọc ở đó. Khi bật, các đối tác trao đổi khung trực tiếp qua cầu, và các điểm lọc của bạn là cầu và tường lửa của máy chủ.
Ghi lại mỗi máy chủ thực sự dựa vào biện pháp bảo vệ nào: xác thực đường hầm, cô lập phân đoạn hay TLS của ứng dụng. Máy chủ dựa vào cả ba thì ổn. Máy chủ chỉ dựa vào cái đầu và cho rằng hai cái kia đi kèm là cái cuối cùng phục vụ nội dung sai.