Hai chặng VPN trên một Pi: tuyến nào chở đối tác nào
Hai địa chỉ đường hầm trên một Pi không phải lỗi. Mỗi đích cần vật chở riêng, bằng chứng riêng và phương án dự phòng đã công bố khi chặng ngoài chết.
Hai địa chỉ đường hầm trên một bo mạch nhỏ trông như nhầm lẫn, và phản xạ là xóa một cái. Phản xạ đó phá hỏng chính thứ nó định dọn gọn. Một máy chủ mang hai chặng giữ một địa chỉ cho mỗi kết nối, và mỗi địa chỉ được một tuyến khác nhau chọn. Câu hỏi đáng đặt ra là tuyến nào chọn vật chở nào cho đích nào, không phải có bao nhiêu địa chỉ.
Ba đích cần vật chở khác nhau
Chuỗi hai chặng là ba lớp đích xếp chồng, và mỗi lớp do một kết nối khác chở. Đối tác ngoài phải được tới bằng liên kết vật lý. Đối tác trong phải được tới qua đường hầm ngoài. Đích của ứng dụng được phủ phải được tới qua đường hầm trong, mà vận chuyển của chính nó do lớp ngoài chở.
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
Điền các hàng bằng địa chỉ thật của người đọc trước khi chạm vào tuyến, vì bảng chỉ hữu ích khi cụ thể. Một chuỗi hoạt động thỏa cả bốn hàng cùng lúc, và một chuỗi nửa hoạt động thường thỏa một trong số đó với vật chở sai. Chính việc đọc nhầm hàng như lỗi khiến một vấn đề định tuyến thành cả buổi chiều sửa chữa.
Địa chỉ có vai trò, không phải số lượng
Linux cho phép nhiều địa chỉ trên một giao diện và nhiều đường hầm trên một máy chủ, nên số lượng không nói gì về tính đúng đắn. Điều quan trọng là địa chỉ nào thuộc kết nối nào, và tuyến cho một đối tác nhất định có chọn đúng kết nối bạn định không. Ba góc nhìn trả lời điều đó từ ba hướng, và đáng đọc chúng theo cùng thứ tự mỗi lần.
Bản kê địa chỉ cho thấy cái gì tồn tại và kết nối nào sở hữu nó. Bảng tuyến trả lời câu hỏi vật chở cho lưu lượng đích thông thường. Góc nhìn chính sách trả lời lại cho lưu lượng được chọn theo nguồn hoặc dấu, cách bố trí bình thường khi hai máy khách chia sẻ một máy chủ.
ip -4 addr show
ip -4 route show table all
ip rule showXóa một địa chỉ vì danh sách trông dài có thể bỏ mất một phần đường đi, và xóa một tuyến vì trông thừa làm điều tương tự lặng lẽ hơn. Cả hai đều không sinh lỗi; đối tác chỉ ngừng trả lời trên đường bạn định trong khi vẫn tới được bằng đường khác. Một ứng dụng báo địa chỉ ra của đối tác trong không chứng minh lưu lượng đã đi qua đường hầm ngoài, vì truy cập trực tiếp cho cùng quan sát đó. Chính khoảng cách giữa quan sát và bằng chứng là lý do vật chở được kiểm tra ở lớp định tuyến.
Thứ tự kích hoạt thắng một giấc ngủ cố định
Nếu máy khách trong phụ thuộc vào một địa chỉ hoặc tuyến do máy khách ngoài cung cấp, việc kích hoạt phải chờ tài nguyên đó thay vì chờ một độ trễ. Giấc ngủ cố định hoạt động cho đến ngày đường hầm ngoài chậm, và khi đó nó hỏng từng lúc theo cách không ai tái tạo được. Thứ tự dựa trên phụ thuộc loại bỏ phỏng đoán và không tốn gì ngoài việc mô tả phụ thuộc một lần. Tên giao diện cũng không phải cơ chế thứ tự.
Nhân hệ điều hành cấp tên như tun0 và tun1 theo thứ tự tạo, và thứ tự đó có thể thay đổi giữa các lần khởi động lại hoặc kết nối lại. Gắn cấu hình với danh tính do công cụ cung cấp, hoặc với tên bạn cố ý gán. Tên bạn chọn là hợp đồng; tên nhân chọn là ngẫu nhiên.
Giữ vận chuyển của mỗi máy khách ngoài tuyến ứng dụng của máy kia, và chính xác về điều các tùy chọn định tuyến của OpenVPN 2.6 thực sự hứa. Cơ chế chuyển hướng mặc định đã được ghi lại giữ máy khách tới được đối tác xa của chính nó qua cổng đã tồn tại, điều này cắt một vòng đệ quy cụ thể. Nó không biến một máy khách thành vật chở của máy khác, nên phần còn lại của chuỗi vẫn là thiết kế của bạn. Ở đâu chuỗi cần chính sách thay vì tuyến, hãy viết một quy tắc nguồn hoặc dấu rõ ràng và thử nó với lưu lượng mà nó phải khớp.
Điều gì xảy ra khi chặng ngoài chết
Trước khi chuỗi được coi là đầy đủ, hãy quyết định điều gì xảy ra khi chặng ngoài biến mất. Vận chuyển của máy khách trong chết theo nó, và bước tiếp theo là câu hỏi chính sách chứ không phải kỹ thuật: hỏng, thử lại, hoặc kết nối lại trực tiếp qua liên kết vật lý. Chính kết quả thứ ba là điều đáng nghĩ. Nó lặng lẽ biến thiết kế hai chặng thành thiết kế một chặng ngay lúc người dùng tin rằng vùng phủ vẫn nguyên vẹn.
Nếu hai chặng là bắt buộc, máy khách trong không được phép lập đường trực tiếp khi chặng ngoài mất, và cách biết là phá chặng ngoài rồi quan sát chặng trong làm gì. Phương án dự phòng đã duyệt là câu trả lời hợp lệ, nhưng phải được viết ra, thử nghiệm và thông báo. Phương án dự phòng không ai ghi lại thì không thể phân biệt với rò rỉ khi rà soát sự cố.
DNS và họ địa chỉ còn lại thuộc cùng một quyết định. Một truy vấn sinh ra cục bộ theo chính sách của chính máy chủ chứ không theo chính sách của máy khách được chuyển tiếp, nên bộ phân giải chạy được cho lưu lượng chuyển tiếp có thể không phải cái máy chủ tự dùng.
Chấp nhận từng lớp theo thứ tự bạn đã dựng nó
Thử theo thứ tự chuỗi được dựng: trước hết riêng đường hầm ngoài, sau đó vận chuyển của máy khách trong qua đường hầm ngoài, sau đó ứng dụng qua đường hầm trong. Mỗi lần chấp nhận phải là một kết nối mới chứ không phải trang đã mở sẵn. Sau đó phá và khôi phục từng lớp riêng rẽ và quan sát lớp kế tiếp làm gì.
Kết quả của phương án dự phòng là quan sát giá trị nhất ở đây, và là thứ một trang IP công cộng không bao giờ hiển thị. Lưu các đường của đối tác, những địa chỉ họ dùng và kết quả đó bên cạnh cấu hình, vì con đường hạnh phúc không phải phần bị chất vấn sau này.