Địa chỉ đường hầm tĩnh trong pfSense: ưu tiên hay đặt trước?

Hai thiết kế trông giống nhau trên giấy và hành xử rất khác khi một quy tắc phụ thuộc vào chúng. Một bên gõ một địa chỉ vào ghi đè máy khách và tin địa chỉ đó như danh tính. Bên kia đóng hoàn toàn việc tiếp nhận động, nên một đầu cuối hoặc có một phép gán duy nhất hoặc không kết nối. Chỉ cách thứ hai biến một địa chỉ thành đầu vào chính sách mà bạn có thể bảo vệ, và sự khác biệt này đáng hiểu trước khi viết dù chỉ một quy tắc tường lửa.

Một địa chỉ ghi đè thực sự hứa gì

Ghi đè riêng cho máy khách mang các tùy chọn theo từng máy khách, trong đó có một địa chỉ đường hầm ưu tiên. Netgate mô tả địa chỉ đó là ưu tiên chứ không phải đặt trước, nghĩa là nhóm động không nhường địa chỉ cho ai khác.

Điều đó thường ổn. Xung đột là hiếm, và máy khách thường nhận được thứ nó yêu cầu, đủ cho sự tiện lợi và không đủ cho việc cấp quyền. Tiện lợi và cấp quyền là những yêu cầu khác nhau, và chỉ một trong hai sống sót qua một xung đột.

Với cấu trúc mạng con, trường này nhận địa chỉ máy khách cùng với mặt nạ của mạng máy chủ, nên một địa chỉ bên trong đường hầm 10.90.0.0/24 được viết là 10.90.0.10/24.

Không điều nào trong số đó đặt trước con số. Một máy khách có ghi đè không khớp, hoặc một phiên trùng lặp, có thể rơi vào chỗ khác trong nhóm, và một quy tắc dựa trên địa chỉ khi đó mô tả một người không ở đó.

Đóng đường động bằng một mặc định có phạm vi

Giải pháp thay thế là một máy chủ chỉ tĩnh: mọi đầu cuối được chấp nhận có danh tính riêng và địa chỉ duy nhất riêng, và không gì khác đi vào.

Triển khai nó nghĩa là một ghi đè DEFAULT được giới hạn cho đúng máy chủ đó với chặn kết nối được bật. Khi đó một máy khách không có ghi đè khớp sẽ không thể quay lại việc tiếp nhận động thông thường. Chính dòng duy nhất đó biến một ưu tiên thành một tập đóng.

Phạm vi rất quan trọng. Một ghi đè mặc định áp cho mọi phiên bản VPN trên thiết bị sẽ khóa các đường hầm không liên quan, và sự cố đó trông giống một dịch vụ hỏng hơn là một quyết định chính sách. Hãy gắn nó với đúng máy chủ mà bạn đang đổi mô hình tiếp nhận. Sau đó ghi phạm vi vào nhật ký thay đổi, vì người tiếp theo sẽ không nhớ nó thuộc đường hầm nào.

Sau đó kiểm toán toàn bộ tập được phép. Chặn mặc định không sửa một ghi đè có tên bị bỏ lại mà không có địa chỉ, và đầu cuối đó sẽ đơn giản không kết nối được mà không có gợi ý rõ ràng vì sao.

Khớp với danh tính mà máy chủ thực sự dùng

Một ghi đè khớp với một thứ gì đó. Trên một máy chủ khớp theo tên chung của chứng chỉ, tên ghi đè phải là tên chung đó, không phải tên hiển thị của người. Hãy sao chép nó từ chứng chỉ chứ không phải từ danh sách tài khoản.

Một máy chủ được cấu hình dùng tên người dùng làm tên chung sẽ khớp trên một khóa hoàn toàn khác, và một ghi đè đặt tên theo chứng chỉ sẽ không bao giờ kích hoạt. Hãy đọc thiết lập thay vì suy ra nó từ những gì danh sách tài khoản hiển thị.

Giữ các yếu tố xác thực bổ sung mà việc triển khai yêu cầu. Một mô hình địa chỉ đóng thay đổi ai có thể kết nối và họ nhận địa chỉ nào; nó không thay thế việc kiểm tra chứng chỉ hay yếu tố thứ hai.

Viết các quy tắc truy cập sau khi bản đồ đã chuẩn

Khi bản đồ từ danh tính sang địa chỉ đã đóng, các quy tắc có thể tham chiếu địa chỉ mà không giả vờ rằng chúng là người. Một bí danh nhóm các đầu cuối của một người có thể chạm tới một dịch vụ cụ thể trong khi một bí danh khác chạm tới thứ khác. Bí danh trở thành đối tượng có thể xem xét, và địa chỉ trở thành một chi tiết triển khai bên trong nó.

Giữ đích và cổng một cách rõ ràng. Cho phép toàn bộ mạng cục bộ từ toàn bộ nhóm đường hầm chính là thiết kế mà bài tập này muốn thay thế.

Đọc các quy tắc nổi, nhóm và giao diện theo đúng thứ tự đánh giá thực tế, vì một lượt cho phép rộng trước đó sẽ vô hiệu hóa một lượt hẹp sau đó. Tắt chuyển tiếp nội bộ giữa các máy khách giữ lưu lượng giữa các đồng đẳng ở ranh giới nơi các quy tắc đó được xem xét. Một quy tắc chỉ tồn tại trên giấy không phải là việc thực thi.

Kiểm tra các trường hợp phủ định

Thử bốn kết nối mới: một đầu cuối có tên, một đầu cuối không có ghi đè nào, một dịch vụ nên truy cập được và một dịch vụ không nên. Đầu cuối không có trong danh sách là trường hợp quan trọng, vì thiết kế tồn tại để chặn nó. Nếu nó kết nối được thì chặn mặc định đang không làm việc của nó.

Kiểm tra IPv6 riêng, vì một chính sách địa chỉ IPv4 không nói gì về ngăn xếp thứ hai. Sau đó xác nhận ứng dụng vẫn cấp quyền cho người dùng, vì địa chỉ đường hầm là một sự thật mạng chứ không phải bằng chứng về ai đang ngồi trước bàn phím. Cả hai kiểm tra đều thuộc về biên bản nghiệm thu.

Cuối cùng, hãy lập kế hoạch di chuyển. Các ghi đè mới và quy tắc hẹp không thay đổi hồi tố các phiên đã thiết lập, nên các trạng thái hiện có phải hết hạn hoặc bị xóa một cách có chủ đích.