Đường hầm toàn phần có đơn giản hơn danh sách đường hầm chia tách dài không?

Danh sách đường hầm chia tách bắt đầu với ba ứng dụng và cuối cùng bao phủ phần lớn máy, mỗi dòng mới là ngoại lệ của ai đó. Đến lúc đó danh sách đã lặng lẽ trở thành một mặc định với thêm vài bước. Đường hầm toàn phần đảo ngược cách sắp xếp: mọi thứ đi vào đường hầm trừ khi một ngoại lệ được ghi chép nói khác. Việc đó có đơn giản hơn hay không phụ thuộc vào cổng và các dịch vụ cục bộ mà bạn sẽ làm hỏng.

Bắt đầu bằng việc đếm các quy tắc bạn duy trì

Đếm các mục, rồi đếm xem bao nhiêu mục có chủ sở hữu được nêu tên và ngày xác minh lần cuối. Con số thứ hai mới là quan trọng, vì một ngoại lệ không có chủ không thể được đánh giá khi phần mềm mà nó tham chiếu bị đổi tên hoặc thay thế. Các quy tắc gắn với đường dẫn tệp thực thi âm thầm hỏng sau một bản cập nhật, và lỗi trông giống VPN chập chờn hơn là một quy tắc cũ. Viết danh sách ra trước khi bạn có ý kiến về nó.

Mỗi mục nên trả lời ba câu hỏi: điều gì hỏng nếu không có nó, ai đã quyết định điều đó, và bạn sẽ nhận ra thế nào nếu lý do đã hết hạn. Những mục không trả lời được cả ba là ứng viên để xóa chứ không phải để chuyển, và xóa chúng trước khiến phép so sánh sau này trung thực.

Nếu phần lớn mục định tuyến một phần lưu lượng lớn, bạn đã chạy một đường hầm toàn phần kèm gánh nặng bảo trì. Khi đó quyết định là mặc định nằm ở đâu, chứ không phải có nên có hay không.

Kiểm tra xem cổng có mang được mặc định không

Đường hầm toàn phần chuyển mọi gói tin tới một thiết bị, điều này đồng thời thay đổi tải CPU, bảng conntrack, dịch địa chỉ và yêu cầu băng thông lên của thiết bị đó. Một cổng từng phục vụ thoải mái vài mạng con nội bộ có thể chưa được tính cho toàn bộ việc duyệt web của một người dùng. Hãy nhìn số phiên đồng thời lớn nhất mà bạn dự kiến thay vì mức trung bình, vì đỉnh là thứ vỡ trước.

ip -s link show dev tun0
conntrack -C
ss -s

Hãy đo cùng khối lượng công việc trước và sau thay đổi thay vì suy luận từ thông số kỹ thuật. Một buổi chiều dùng bình thường trên một máy sẽ cho thấy cổng có gần giới hạn hay không, và việc này không tốn gì so với phát hiện ra vào một sáng thứ Hai.

Cũng nên kiểm tra path MTU từ đầu đến cuối, vì một mặc định toàn phần khiến mọi ứng dụng đối mặt với kích thước gói tối đa của đường hầm. Những ứng dụng từng chạy ngoài đường hầm nay có thể phụ thuộc vào hành vi phân mảnh mà bạn chưa từng phải nghĩ tới.

Xác nhận dịch vụ cục bộ và DNS riêng vẫn hoạt động

Liệt kê những gì phải ở lại cục bộ theo giao thức chứ không theo tên ứng dụng: giao thức khám phá cho máy in và màn hình, cầu nối nhà thông minh, trang quản trị của router, một máy chủ phát triển cục bộ truy cập qua tên chỉ phân giải trong LAN. Những thứ đó hỏng khi tuyến mặc định bắt đầu trỏ vào đường hầm, và chúng hỏng âm thầm vì không có gì ghi lỗi ở máy khách.

DNS riêng là phụ thuộc còn lại. Nếu tên nội bộ trước đây được phân giải bởi trình phân giải của đường hầm thì không có gì thay đổi; nếu chúng được phân giải cục bộ, một mặc định toàn phần phải đưa chúng tới trình phân giải biết các vùng. Hãy thử một tên nội bộ và một tên công cộng sau thay đổi thay vì giả định danh sách trình phân giải còn nguyên.

Viết các ngoại lệ cục bộ vào hồ sơ sở hữu chúng. Một ngoại lệ chỉ được giữ trong trí nhớ của ai đó là thứ đầu tiên lần chuyển đổi tiếp theo đánh mất.

Chuyển một hồ sơ và xác minh các biên

Thay đổi hồ sơ thông qua cấu hình sở hữu nó, thay vì chồng một mặc định mới lên các tuyến thủ công còn sót lại từ những thử nghiệm trước. Những tuyến còn sót đó là nguyên nhân thường gặp của một lần chuyển trông có vẻ hoạt động và cư xử không nhất quán một ngày sau. Giữ hồ sơ cũ sẵn dùng để việc quay lui là một lựa chọn chứ không phải dựng lại.

Sau đó xác minh hai biên riêng rẽ: đích công cộng và riêng tư đều hoạt động, và lưu lượng không mong muốn không đi ra ngoài đường hầm. Một lần tải trang thành công chứng minh điều thứ nhất và không nói gì về điều thứ hai.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Lặp lại kiểm tra sau khi kết nối lại và sau khi mất kết nối, vì một kill switch chặn lưu lượng trong lúc rớt là thuộc tính khác với một tuyến khôi phục đúng sau đó. Thiết kế đơn giản hơn là thiết kế mà bạn vẫn giải thích được phạm vi phủ thực sự của nó sau khi một ứng dụng hoặc một mạng thay đổi.