pfSense vừa là máy chủ vừa là máy khách VPN: hai đường đi, một router

Một thiết bị có thể nhìn về hai hướng cùng lúc: người dùng di động kết nối vào trong, và cùng chiếc hộp đó kết nối ra ngoài tới một nhà cung cấp lối ra để lưu lượng được chọn thoát qua một mạng khác. Bật cả hai dịch vụ chỉ mất vài phút; cho chúng cùng tồn tại lại cần một thiết kế, vì vai trò thứ hai ghi lại bảng định tuyến mà vai trò thứ nhất dựa vào. Ba điều kiện quyết định cách sắp xếp có chạy được hay không, cụ thể là dịch vụ vào có giữ đường quay về của riêng nó, đường hầm ra có còn tới được đối tác của nó, và lưu lượng bạn định chuyển tiếp có được chọn cho lối ra hay không. Sai một điều, bạn nhận được hai đường hầm cùng báo đã kết nối trong khi chẳng có gì hữu ích đi qua giữa chúng. Các kiểm tra bên dưới xác lập từng điều kiện theo thứ tự sự cố thường xuất hiện.

Đặt tên hai vai trò trước khi chạm vào bất kỳ thiết lập nào

Ghi lại bốn dữ kiện cho mỗi phiên bản: đối tác từ xa, vật liệu xác thực, nhóm địa chỉ nó cấp phát, và các mạng phía sau nó. Hai phiên bản là những đối tượng riêng trên thiết bị và cũng nên tách riêng trong ghi chú của bạn. Gần như mọi triệu chứng khó hiểu về sau đều đến từ việc trộn lẫn giá trị của chúng, và hai phiên bản dùng chung một bộ ghi chú chính là cách nhóm sai rơi vào ô sai.

Dịch vụ vào cần một mạng đường hầm không chồng lấn với địa chỉ của đường hầm ra hay bất kỳ mạng riêng nào mà thiết bị định tuyến. Chồng lấn là lỗi duy nhất gây triệu chứng ở cả hai vai trò cùng lúc, và bắt nó trên giấy rẻ hơn nhiều. So sánh cả hai nhóm và mọi mạng riêng được định tuyến ở một chỗ trước khi cấu hình bất kỳ dịch vụ nào.

Phần cứng dùng chung không có nghĩa là thông tin đăng nhập dùng chung, và chứng chỉ máy khách từ nhóm truy cập từ xa không nên dùng được với nhà cung cấp lối ra. Vật liệu riêng cũng biến việc thu hồi thành quyết định cục bộ thay vì sự kiện của toàn bộ đội.

Giữ các phản hồi của máy chủ trên đường WAN

Những phản hồi do chính thiết bị tạo ra là nạn nhân đầu tiên của một tuyến mặc định cẩu thả. Khi gói được đóng gói của người dùng di động đến, phản hồi là lưu lượng sinh ra cục bộ và phải đi ra qua đúng giao diện mà người dùng đó đã vào. Nếu máy khách ra đã cài một tuyến mặc định bắt lấy nó, phản hồi rơi vào đường hầm sai và phiên bị kẹt trong khi dịch vụ vẫn trông khỏe mạnh.

Không có một ô kiểm duy nhất giải quyết việc này, vì quyết định là về việc máy khách ra được phép bắt lưu lượng nào. Hoặc không kéo tuyến nào và chỉ dẫn hướng những gì bạn chọn, hoặc kéo các tuyến và thêm những ngoại lệ giữ cho các dịch vụ của chính thiết bị tiếp tục chạy. Ghi lựa chọn bên cạnh phiên bản, nếu không người tiếp theo sẽ giả định điều ngược lại.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Đọc bảng định tuyến theo khớp dài nhất chứ không theo thứ tự bạn đã cấu hình bất cứ thứ gì. Câu hỏi là mục nào thắng cho địa chỉ của đối tác ra và mục nào thắng cho phản hồi của dịch vụ vào, và hai câu trả lời đó có thể khác nhau.

Đừng để đường hầm ra ăn mất điểm cuối của chính nó

Máy khách ra phải tới được địa chỉ công khai của đối tác thì mới dựng được đường hầm. Nếu chính địa chỉ đó bị định tuyến vào trong đường hầm, máy khách tự đuổi theo đuôi mình: đường truyền không bao giờ lên, hoặc lên rồi rơi đúng lúc tuyến được cài vào. Nhật ký trông như hết hạn xác thực chứ không phải lỗi định tuyến, vì thế tuyến đáng được kiểm tra trước.

Kiểm tra tuyến trước thông tin đăng nhập và một lần nữa sau khi đường hầm lên, vì một mục có thể đúng lúc khởi động và sai một phút sau. Địa chỉ của đối tác phải trỏ về đường WAN thông thường, không bao giờ trỏ vào thiết bị đường hầm. Khi đường truyền ổn định, câu hỏi thú vị chuyển sang lưu lượng được chuyển tiếp, và đó là quyết định tiếp theo.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Chọn những người dùng nào được lối ra

Chính sách nguồn thuộc về lối vào nơi lưu lượng đi vào thiết bị, vì vậy hãy chọn nhóm truy cập từ xa, hoặc những danh tính hẹp hơn bên trong nó. Giữ lại những đích riêng và ngoại lệ quản trị không bao giờ được gửi tới lối ra, và đặt những quy tắc đó trước quy tắc rộng. Sau đó đường ra cần bản dịch của riêng nó hoặc một cách sắp xếp quay về được định tuyến, mà với phần lớn thiết kế nghĩa là NAT ra trên giao diện ra bao trùm nhóm địa chỉ. Bản dịch không chọn lối ra; nó chỉ ghi lại thứ đã rời đi, nên một quy tắc NAT trên WAN không liên quan không thay đổi gì trong việc chọn.

Xác nhận đầu xa cho phép lưu lượng được chuyển tiếp từ thiết kế này, vì có nhà cung cấp cho phép và có nơi không. Khác biệt hiện ra như một đường hầm kết nối mà không chở gì, thứ dễ bị đọc nhầm thành lỗi cục bộ. Thử ba luồng riêng rẽ, vì chúng hỏng độc lập, và hai trên ba nghĩa là thiết kế mới xây một nửa.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Lệnh đầu tiên là kết nối bên ngoài của người dùng di động, và nó chạy khi máy khách báo chuỗi khởi tạo đã hoàn tất. Lệnh thứ hai, chạy từ chiếc laptop đã kết nối đó, phải báo địa chỉ của nhà cung cấp lối ra thay vì địa chỉ WAN của bạn. Lệnh thứ ba chạy trên thiết bị gắn với một địa chỉ trong nhóm, và nó kiểm tra chính sách nguồn cho lưu lượng được chuyển tiếp mà không hề lôi kéo người dùng từ xa nào. Nếu thay vào đó nó trả lời từ WAN, chính sách đã không khớp, và không lượng sửa NAT nào sửa được vấn đề chọn đường.

Quyết định điều gì xảy ra khi lối ra hỏng

Ghi lại hành vi khi hỏng trước khi nó xảy ra: khi đường hầm ra rơi, người dùng quay về WAN thông thường hay bị chặn cho tới khi lối ra trở lại? Cả hai câu trả lời đều có thể bảo vệ được, và thiết bị sẽ không chọn thay bạn. Một tuyến bị gỡ bỏ hay một chính sách trỏ tới cổng đã chết không tự động tạo ra kết quả chặn hoàn toàn. Nếu muốn chặn, chính sách phải nói rõ điều đó, và phải thử bằng cách lấy lối ra đi chứ không phải bằng cách suy nghĩ về nó. Nếu muốn quay về, hãy công bố điều đó cho người dùng, vì lưu lượng lặng lẽ đi theo đường thông thường chính là lưu lượng mà ai đó tưởng đã được che phủ.

Tắt phiên bản máy khách, xem người dùng đang kết nối còn tới được gì, rồi bật lại. Yêu cầu hết thời gian chính là kết quả chặn hoàn toàn mà bạn yêu cầu; yêu cầu trả lời bằng địa chỉ WAN là sự quay về mà bạn không ghi lại. Lặp lại kiểm tra cho IPv6 và DNS, vì một chính sách viết cho IPv4 không nói gì về lưu lượng AAAA và bất kỳ bộ phân giải nào bị đẩy xuống đều trả lời từ nơi truy vấn thực sự đi ra.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Công thức OpenVPN được định tuyến của Netgate cho thấy chính sách nguồn, việc gán giao diện và bản dịch ra khớp với nhau thế nào, và phạm vi từ site đến site của nó là phần không nên sao chép toàn bộ. Điều nó sẽ không nói cho bạn là điều kiện nào trong ba điều kiện trên đã bị chính thiết kế của bạn phá vỡ.