Tunnel toàn phần FortiClient: chỉ định tuyến phân mạng văn phòng

Đường hầm bật lên, biểu tượng chuyển sang màu xanh và mạng cục bộ biến mất: máy in, NAS và router văn phòng đều ngừng phản hồi. FortiClient đang làm đúng điều hồ sơ yêu cầu. Gateway đẩy xuống một tuyến mặc định, ứng dụng cài nó, và giờ mỗi gói tin đều có đường vào đường hầm. Cách sửa là chỉnh bảng định tuyến kèm một chỉnh sửa DNS phía sau, và thứ tự của hai chỉnh sửa này quyết định máy sẽ kết thúc tốt hơn hay tệ hơn.

Ứng dụng đã cài gì, và vì sao LAN biến mất

Hãy bắt đầu bằng việc đọc bảng định tuyến thay vì giao diện của ứng dụng. Trên macOS netstat -rn in toàn bộ bảng và route -n get default nêu tên giao diện cùng metric đang thắng; trên Linux cặp lệnh là ip route show và ip route get 8.8.8.8. Cả hai trả lời một câu hỏi: mục nào sẽ chở một gói tin không khớp với bất cứ thứ gì cụ thể hơn.

Tên thiết bị đường hầm không cố định. Một hồ sơ IKEv2 trên macOS thường hiển thị utun kèm số, ứng dụng SSL VPN hiển thị ppp0, còn OpenVPN hiển thị tun0. Hai tuyến mặc định cũng có thể cùng tồn tại với metric khác nhau, và mục của ứng dụng có thể chỉ tiếp quản sau khi kết nối lại chứ không phải ngay khi nó xuất hiện. Đó là lý do hai lần kết xuất bảng cách nhau năm phút có thể kể hai câu chuyện khác nhau.

Vì sao tuyến mặc định của đường hầm phải đi trước

Nhân hệ điều hành chọn tiền tố khớp dài nhất, và khi nhiều tuyến cụ thể ngang nhau thì chọn tuyến có metric thấp nhất. Vì vậy ứng dụng cài 0.0.0.0/0 với metric tốt hơn sẽ thắng mọi điểm đến mà không xóa tuyến mặc định gốc, và đó là lý do tuyến vật lý vẫn còn trong bảng và vẫn giải thích được sự cố. Xóa tuyến mặc định của đường hầm trước sẽ khôi phục hành vi cũ. Chỉ sau đó một tuyến tiền tố qua đường hầm mới làm đúng điều tác giả của nó muốn.

Thêm tiền tố trước bước đó chính là lỗi tạo ra một cỗ máy chỉ chạy được nửa. Lưu lượng của tiền tố mới đi qua đường hầm, và mọi thứ không có trong danh sách cũng đi theo tuyến mặc định của đường hầm, nên không có gì trông hỏng cho tới khi ai đó mở một dịch vụ mà không ai thêm vào. Xóa, khôi phục, rồi mới thêm, và trạng thái trung gian vẫn dự đoán được.

Trình tự trên macOS và trên Linux

Trên macOS, trình tự này xóa tuyến mặc định của đường hầm, khôi phục tuyến mặc định vật lý và đưa một tiền tố văn phòng trở lại đường hầm. Hãy thay các tên giao diện minh họa ở đây bằng tên trong bảng của chính bạn.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

Trên Linux, cùng trình tự đó dùng một công cụ khác: gateway của LAN cho tuyến mặc định và thiết bị đường hầm cho tiền tố văn phòng. Lệnh route cũ vẫn chấp nhận cú pháp cũ, nhưng ip route mới là dạng khớp với tài liệu hiện hành.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Khi tuyến cần một bước nhảy kế tiếp thay vì một thiết bị, hãy lấy peer từ đầu ra của ứng dụng. Đoán mò sẽ cho một trong hai lỗi, và chúng có nghĩa khác nhau: gateway sai cho network unreachable ngay lập tức, còn đích đường hầm sai cho hết thời gian chờ. Hãy đọc xem bạn gặp lỗi nào trước khi đổi lệnh lần nữa.

Tiền tố, trình phân giải và DMZ mãi tối

Một tiền tố hiếm khi phủ hết công việc. Máy chủ ứng dụng, mạng quản trị, DMZ và chính các máy chủ DNS có thể nằm ở các dải khác nhau, nên hãy liệt kê mọi dải bạn gọi được tên trước khi bắt đầu và thử một truy vấn bên cạnh mỗi lần ping. Đích được phát hiện giữa lúc kiểm tra chính là thứ bị bỏ quên trong biên bản thay đổi. Một tuyến trả lời theo địa chỉ nhưng thất bại theo tên thường là vấn đề của trình phân giải khoác áo định tuyến.

Trình phân giải là một quyết định riêng. Khi hồ sơ đẩy xuống máy chủ DNS nội bộ, việc bỏ tuyến mặc định có thể khiến các địa chỉ đó không tới được cho tên công cộng, hoặc chỉ tới được qua đường hầm, và cả hai trạng thái đều cho kết quả một phần khó hiểu. Hãy định tuyến địa chỉ của trình phân giải qua đường hầm, hoặc cấu hình phân giải theo từng tên miền để truy vấn công cộng dùng trình phân giải cục bộ.

Ứng dụng SSL trên Linux có một lỗi đặc thù theo trường đáng để biết: đường hầm kết nối được, LAN văn phòng trả lời, nhưng một dải DMZ vẫn tối. Phần còn thiếu là tuyến cho dải đó qua gateway của đường hầm, và gateway khác nhau giữa các máy, nên địa chỉ mã hóa cứng chính là cách chiếc laptop kế tiếp hỏng. Hãy suy ra nó từ trạng thái của ứng dụng và giữ lệnh tự mô tả:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Hãy đọc hai giá trị trước khi chạy. peer là đầu xa của đường hầm điểm-điểm, và đó là địa chỉ mà tuyến DMZ cần; với đường hầm được định tuyến, tương đương là giao diện hoặc gateway mà ứng dụng báo cáo. Nếu không cái nào xuất hiện, ứng dụng không ở chế độ bạn giả định.

Sau lần kết nối kế tiếp, và khi nào nên thôi làm việc này cục bộ

FortiClient kết nối lại sau khi ngủ hoặc khi mạng thay đổi và cài lại những gì hồ sơ quy định. Vì vậy các tuyến thủ công chỉ sống tới lần kết nối kế tiếp, và đó đúng là khoảng thời gian mà một lần kiểm tra thành công có thể trông giống một bản sửa. Một tuyến biến mất qua đêm là hành vi dự kiến, không phải sự cố mới.

Có hai câu trả lời bền vững. Một script chạy lại phần chỉnh sửa sau mỗi lần kết nối là giải pháp vòng vo có thể sống lâu hơn tác giả của nó, trong khi hồ sơ tunnel chia tách do quản trị viên gateway cung cấp mới là bản sửa thật, vì khi đó ứng dụng chỉ cài những dải mà công việc cần. Hãy yêu cầu cái thứ hai và chỉ dùng cái thứ nhất trong lúc chờ. Cũng hãy kiểm tra chính sách bạn đã đồng ý trước khi chia tách toàn bộ đường hầm tại máy, vì mạng từ xa có thể dựa vào việc nhìn thấy toàn bộ lưu lượng của bạn.

Danh sách kiểm tra ngắn gọn: đọc bảng, xóa tuyến mặc định của đường hầm, khôi phục tuyến mặc định của LAN, thêm từng tiền tố, sửa phân giải riêng, và dự kiến các tuyến sẽ trở lại khi kết nối lại.