Một người dùng VPN cần một máy in, không phải cả mạng LAN

Quy tắc trông đúng mà máy in vẫn từ chối. Hoặc máy in hoạt động và cùng người dùng đó còn truy cập được máy chủ tệp, điều này tệ hơn. Cả hai kết quả thường đến từ cùng một chỗ: quy tắc hẹp được thêm vào một bộ quy tắc vốn đã cho phép thứ gì đó rộng hơn. Đọc thứ tự hiệu lực giải thích kết quả trước khi bất kỳ quy tắc mới nào được viết.

Triệu chứng: quy tắc hẹp không thay đổi gì

Một nhóm VPN riêng, một địa chỉ máy in và một quy tắc cho phép trên TCP 631 là thiết kế hợp lý. Khi nó không tạo ra thay đổi nào, nghi ngờ đầu tiên phải là lưu lượng chưa bao giờ đến quy tắc đó. Một quy tắc chỉ quyết định cho lưu lượng đến vị trí của nó trong thứ tự đánh giá. Các trường dễ kiểm tra và hiếm khi là nguyên nhân thất bại.

Triệu chứng ngược lại dễ bị bỏ qua hơn. Công việc in thành công, và một kết nối tới chia sẻ tệp mà người dùng này không bao giờ được phép chạm tới cũng thành công. Điều đó nghĩa là một thứ gì đó trước đó đã cho phép mạng LAN.

Cả hai triệu chứng đều chỉ vào thứ tự chứ không phải các trường của quy tắc mới. Một là quy tắc chưa bao giờ khớp, và cái kia là quy tắc khớp quá sớm.

Lưu lượng thực sự rơi vào bộ quy tắc nào

pfSense đánh giá quy tắc theo từng giao diện, và OpenVPN có tab riêng với các quy tắc áp dụng cho mọi phiên bản máy chủ và máy khách. Những quy tắc đó được xử lý trước các quy tắc được gán cho một giao diện OpenVPN cụ thể. Vì vậy một cho phép rộng còn lại trên tab OpenVPN cũng áp dụng cho người dùng này, bất kể tab giao diện nói gì. Sao chép thứ tự đó vào hồ sơ thay đổi để quá trình xem xét có thể kiểm tra mà không cần mở GUI.

Đó là lý do một cho phép hẹp mới không thể lấy lại quyền truy cập. Các quy tắc tường lửa thêm quyền và không lấy nó khỏi một lần khớp trước đó.

Đọc danh sách hiệu lực từ trên xuống và dừng ở quy tắc đầu tiên khớp với lưu lượng. Lần khớp đầu tiên đó là quyết định, và mọi thứ bên dưới đều không thể tiếp cận với luồng đó.

Viết quy tắc cho phép từ công việc in

Bắt đầu từ công việc chứ không phải từ máy in. Người dùng cần dịch vụ in trên địa chỉ máy in, nên quy tắc nêu địa chỉ đó, giao thức đó và cổng đó. Một bí danh cho nhóm VPN và một bí danh cho máy in giữ quy tắc dễ đọc.

Hãy chống lại khuynh hướng thêm cổng khám phá hoặc quản trị để làm hài lòng một trình hướng dẫn. Một quy tắc cho phép toàn bộ máy in là chính sách khác với quy tắc cho phép một hàng đợi in.

Giữ nguyên xác thực của chính máy in. Cho phép ở mức mạng không thay thế nó. Tài khoản ở cấp hàng đợi là kiểm soát đúng cho việc ai được in gì.

Sáu giá trị mang toàn bộ ý định: cho phép là hành động, IPv4 là họ, TCP là giao thức, bí danh nhóm là nguồn, bí danh máy in là đích và 631 là cổng. Bất cứ điều gì vượt quá sáu giá trị đó là chính sách khác với chính sách được yêu cầu.

Cho máy khách một đường đi mà không cần cho phép mạng LAN

Máy khách cần tuyến đường tới địa chỉ máy in, và phía văn phòng cần đường phản hồi tới nhóm VPN. Đẩy một /32 duy nhất giữ cấu hình máy khách hẹp, điều này giúp khắc phục sự cố. Đây không phải ranh giới phân quyền, vì máy khách có thể tự thêm tuyến đường.

Nếu hàng đợi được định địa chỉ bằng tên, hãy định nghĩa phụ thuộc vào trình phân giải riêng. Cho phép cả mạng LAN chỉ để phân giải một tên là thay đổi lớn hơn nhiều so với yêu cầu của công việc.

Chọn có ý thức giữa định tuyến trở lại nhóm và dịch nguồn. Cả hai đều hoạt động, và mỗi cách che giấu một thứ khác khỏi nhật ký.

Kiểm tra cả việc từ chối lẫn công việc

Gửi một công việc nhỏ, không nhạy cảm từ người dùng VPN, sau đó thử một tài nguyên mạng LAN đáng lẽ phải bị từ chối và chính trang quản trị của tường lửa. Ba bài kiểm tra thuộc cùng một phiên, vì đó là cách duy nhất để thấy chính sách một cách tổng thể. Một công việc in thành công tự nó hầu như không chứng minh được gì về ranh giới.

Xem lại IPv6 và bất kỳ đường VPN đang hoạt động nào khác trước khi gọi việc triển khai là chỉ máy in. Một bộ quy tắc hẹp trong một họ địa chỉ có thể hoàn toàn mở trong họ còn lại.