Vì sao tuyến đường toàn phần của tunnel cắt đứt máy chủ chở nó

Bật tunnel toàn phần và mọi đích đến giờ đều thuộc giao diện VPN, kể cả chiếc máy kết thúc nó. Các gói bên ngoài chở tunnel được gửi tới chính máy đó, nên tuyến đường cuối cùng ăn mất phần vận chuyển mà nó phụ thuộc. Một tuyến cụ thể thêm vào sẽ giải quyết, và lý do đáng để hiểu. Không có lý do đó, lần dựng lại tiếp theo sẽ mang lỗi trở lại.

Một tuyến đường ăn chính vận chuyển của nó

Đóng gói bọc mỗi gói trong một tiêu đề thứ hai. Tiêu đề ngoài được gửi từ địa chỉ vật lý cục bộ tới địa chỉ công khai của máy chủ, và nó phải đi qua liên kết vật lý trước khi bất kỳ tunnel nào có thể tồn tại.

Giờ hãy để việc tra cứu địa chỉ công khai đó chọn tunnel. Để gửi gói đi, máy phải đóng gói nó, việc này cần một tuyến tới cùng địa chỉ, và tuyến đó trả lại tunnel. Các máy khách xử lý việc này theo một trong hai cách. Loại cẩn thận từ chối cài tuyến mặc định và báo lỗi, còn loại kém cẩn thận hơn báo thành công rồi không chuyển gì cả. Thất bại im lặng chính là thứ khiến mất cả buổi chiều.

Việc khớp tiền tố dài nhất quyết định tra cứu trước khi bất kỳ số đo nào được xét, nên một tuyến một địa chỉ vượt mọi tuyến mặc định trên máy. Đó là toàn bộ cơ chế đằng sau việc sửa.

Cài ngoại lệ trước tuyến mặc định

Tạo một tuyến một địa chỉ cho máy chủ, với cổng vật lý làm bước nhảy kế tiếp, trước khi tuyến mặc định dịch chuyển. Thứ tự quan trọng: cài sau nghĩa là sống với tunnel hỏng trong lúc bạn gõ.

Hầu hết máy khách làm việc này mà không cần ai nhắc. OpenVPN tra địa chỉ từ xa và ghim nó trước khi ghi lại cổng mặc định, và tùy chọn route-delay của nó tồn tại cho các nền tảng nơi trình tự đó chạy đua. wg-quick đi một con đường hoàn toàn khác, đánh dấu gói và tham vấn một quy tắc chính sách thay vì thêm một ngoại lệ. Cơ chế khác nhau, yêu cầu giống nhau: gói bên ngoài phải thoát khỏi tunnel mà nó tạo ra.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Kết quả tra cứu là bài kiểm tra chấp nhận. Nó phải nêu tên thiết bị vật lý và bước nhảy vật lý kế tiếp. Một thiết bị tunnel trong câu trả lời đó nghĩa là ngoại lệ thiếu, hoặc bị đặt sau một thứ lấn át nó.

Hình ảnh gương trên máy chủ

Cùng một cái bẫy chờ ở phía bên kia, đảo ngược. Cho máy chủ một tuyến mặc định qua tunnel khác, hoặc đẩy cho nó một tuyến bao trùm các địa chỉ công khai của máy khách, và các phản hồi của nó sẽ nhiễm thói đi sai hướng.

Hãy hình dung một máy khách kết nối và gửi yêu cầu. Phản hồi được gửi tới địa chỉ công khai của máy khách đó, địa chỉ này giờ khớp với một tuyến tunnel, nên nó rời khỏi một giao diện khác mang theo nguồn mà máy khách chưa từng quay số. Máy khách có thể nhận gói đó và vẫn loại bỏ nó, vì không gì buộc nó với yêu cầu đã gửi. Hãy bắt đầu từ quyết định định tuyến của máy chủ chứ không phải từ thời gian chờ của máy khách, vì chỉ một trong hai cho thấy lựa chọn thật sự.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Có ba cách sửa và chúng không ngang nhau. Ghim dịch vụ vào địa chỉ vật lý, hoặc dịch địa chỉ nguồn, cả hai đều giấu quyết định định tuyến thay vì sửa nó. Gửi lưu lượng phản hồi cho bể tunnel qua một bảng riêng mới sửa được nguyên nhân, và hai cách kia chỉ chấp nhận được khi thiết kế định tuyến đang bị đóng băng.

Những ngoại lệ mà tunnel cứ tiếp tục đánh cắp

Một số công việc cần internet mở ngay cả khi tunnel nắm tuyến mặc định, và mỗi việc cần ngoại lệ riêng. Trình cập nhật DNS động thường là thứ hỏng đầu tiên.

Nó phân giải nhà cung cấp, mở kết nối và phát hiện các gói của chính mình đi qua một tunnel vừa đổi địa chỉ vài giây trước, nên lần cập nhật thất bại hoặc công bố sai địa chỉ. Ba lối ra: ghim nhà cung cấp bằng tuyến host qua cổng vật lý, chạy cập nhật trước khi tunnel dựng lên, hoặc cấp cho trình cập nhật một bảng chính sách mà tunnel không bao giờ chạm tới. Đồng bộ thời gian cũng lộ diện như vậy trên thiết bị khởi động không có bộ phân giải, và các điểm cuối xác thực chứng thư cũng nằm trong danh sách vì lý do đó.

Một ngoại lệ không ai ghi lại là ngoại lệ mà lần dựng lại sau sẽ âm thầm bỏ rơi.

Hãy chứng minh sau khi kết nối lại, không phải trước đó

Kiểm tra ba đích đến, không phải một: điểm cuối, một địa chỉ riêng sau tunnel, và một địa chỉ công khai xa hơn. Một lần tra cứu thành công gần như chẳng nói gì về hai cái còn lại.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Rồi khởi động lại kết nối, vì máy khách dựng lại bảng của nó khi kết nối lại sẽ vứt bỏ tuyến bạn gõ tay. Nếu có kill switch, hãy kiểm tra điểm cuối được cho phép, nếu không tunnel không thể trở lại sau khi mạng đổi và triệu chứng trông như mất kết nối. Hãy lưu ngoại lệ trong hồ sơ hoặc tệp unit thay vì lịch sử shell, để lần kết nối lại tạo lại nó chứ không xóa nó đi.