Định tuyến chính sách IPv6 khi hai uplink dùng chung fe80::1
Hai uplink có thể hiển thị cùng một fe80::1 chặng kế tiếp trên các liên kết khác nhau. Chọn một bảng cho mỗi chính sách, tự nắm thời gian sống và xác minh bằng một truy vấn tuyến.
Bạn có hai uplink, và ip -6 route show in ra cùng một chặng kế tiếp trên cả hai: default via fe80::1 dev uplink0 và default via fe80::1 dev uplink1. Đây không phải xung đột địa chỉ trùng lặp, và việc sao chép chặng kế tiếp trần fe80::1 vào một bảng chính sách không cho nhân biết bạn muốn liên kết nào. Câu hỏi thật hẹp hơn triệu chứng gợi ý: bảng thứ hai cần một liên kết hay cả hai, và điều gì giữ những tuyến đó sống sau khi khởi động lại. Ba điều kiện, kiểm tra theo thứ tự, giải quyết phần lớn.
Cùng một fe80::1 là hai láng giềng khác nhau
Địa chỉ liên kết cục bộ chỉ có phạm vi một liên kết, vì vậy fe80::1 không phải một địa chỉ in hai lần; đó là hai láng giềng tình cờ dùng chung hậu tố. Chỉ số vùng là cách máy chủ nói rõ nó muốn cái nào, nên fe80::1%uplink0 và fe80::1%uplink1 là những điểm đích khác nhau với nhân, và hậu tố đó không bao giờ đi tới một bộ định tuyến từ xa. RFC 4007 mô tả mô hình vùng đằng sau điều này, và đó là lý do một bảng chính sách phải mang theo thiết bị với mọi chặng kế tiếp liên kết cục bộ.
Trình tạo cấu hình VPN sao chép một ID vùng dạng số từ máy này sang mẫu coi ngữ cảnh cục bộ như thể nó là một phần của địa chỉ, và tệp nó ghi sai trên mọi máy có tên hoặc chỉ số giao diện khác nhau. Một bảng chính sách cũng không gộp hai liên kết thành một: VPN định tuyến chuyển gói giữa các mạng, nhưng không mang danh tính liên kết cục bộ của một láng giềng Ethernet từ xa qua đường hầm, nên lưu lượng liên kết cục bộ ở lại trên liên kết của nó.
Bỏ thiết bị đi và tuyến trở nên không ghi được. ip -6 route add default via fe80::1 table 200 không phân giải được cổng, và iproute2 từ chối nó với Error: Nexthop has invalid gateway. lỗi. Thêm dev uplink0 và lệnh thành công, vì chính thiết bị ghim chặng kế tiếp vào một trong hai láng giềng đó. Điều thiết bị không thể nói là uplink0 có phải liên kết đúng cho bảng này không, và một tuyến sao chép từ máy khác mang theo tên giao diện của máy đó, và đó là nguồn gốc của những lỗi thật.
Điều kiện một: một liên kết hay hai trong bảng
Bắt đầu từ việc uplink thứ hai dùng để làm gì. Nếu cả hai liên kết chở cùng lưu lượng và một cái là dự phòng, bảng thay thế nên chứa cả hai cổng với metric khác nhau: cùng điểm đích, một đường ưu tiên, một lựa chọn thứ hai rõ ràng. Nếu các uplink tồn tại vì lưu lượng khác nhau phải đi ra qua các nhà cung cấp khác nhau, hoặc vì đây là một đường hầm chia tách trong đó phần lưu lượng bỏ qua VPN còn phần còn lại ở trong, thì hai liên kết đó hoàn toàn không thuộc một bảng. Chúng thuộc hai bảng, được một quy tắc chọn, và quy tắc chọn bảng, không chọn đường hầm: lưu lượng đi vòng được đánh dấu trước khi định tuyến, và chính dấu đó gửi nó sang bảng thứ hai.
Trong trường hợp thứ hai, quy tắc quyết định khi nào tra bảng, và tuyến quyết định gói đi đâu sau đó:
ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201Không đối tượng nào thay thế đối tượng kia, và một bảng chỉ có tuyến mặc định vẫn có thể không phân giải được cổng của nó. Nếu việc thêm bị từ chối, hoặc tuyến có nhưng không dùng được, hãy đặt tiền tố kết nối của giao diện đó vào cùng bảng, hoặc đánh dấu chặng là onlink (khi tiền tố đó được định tuyến ở nơi khác). Trong khối trên, 2001:db8:100::/48 biểu thị tiền tố kết nối đó trên uplink1, không phải một điểm đích tùy ý. Quy tắc fwmark chỉ tiêu thụ một dấu mà thứ khác phải đặt, từ một quy tắc nftables hoặc iptables trên đường chuyển tiếp hoặc từ SO_MARK trên socket, nên một khối sao chép không có nguồn dấu thì không khớp gì cả.
Điều kiện hai: metric không phát hiện nhà cung cấp đã chết
Metric là sự ưu tiên giữa các tuyến đang tồn tại, không phải kiểm tra sức khỏe. Khi nhà mạng sập, nhân gỡ các tuyến trên thiết bị đó và tuyến mặc định thứ hai tiếp quản. Khi cáp vẫn cắm và nhà cung cấp phía sau chết, bảng không thay đổi gì: tuyến ưu tiên vẫn được cài, láng giềng vẫn tới được ở lớp 2, và các gói đi vào một hố đen. Nếu sự khác biệt đó quan trọng với thiết lập của bạn, chuyển đổi dự phòng phải đến từ thứ gì đó thăm dò đường đi và gỡ tuyến, dù đó là một daemon định tuyến hay một script nhỏ xóa và cài lại mục.
Xác minh lựa chọn sau khi bảng được dựng, và xác minh theo cách nhân sẽ nhìn thấy nó. ip -6 route get 2001:db8:100::1 in ra tuyến sẽ được dùng, gồm thiết bị và địa chỉ nguồn được chọn, và nó tôn trọng các quy tắc chính sách. Địa chỉ nguồn thuộc uplink sai là dấu hiệu thường gặp rằng một quy tắc khớp sớm hơn bạn tưởng.
Điều kiện ba: quyết định ai sở hữu tính bền vững
Tuyến được thêm bằng ip -6 route add tồn tại đến khi khởi động lại hoặc đến khi có thứ gì xóa nó. Tuyến mặc định học từ quảng cáo của bộ định tuyến có thời gian sống và bộ định tuyến có thể rút nó, trong khi tuyến mặc định thêm thủ công không bao giờ tự hết hạn. Trộn cả hai trong một bảng là cách một tuyến cố định cũ cuối cùng vượt lên trên một tuyến vừa được quảng cáo, rất lâu sau khi uplink mà nó mô tả không còn tồn tại.
Chọn một chủ sở hữu cho mỗi bảng. Nếu trình quản lý mạng hoặc daemon định tuyến đã quản lý giao diện, hãy mô tả tuyến chính sách ở đó và để yên nhân. Nếu bạn làm bằng script, hãy làm nó idempotent và viết phần tháo gỡ cùng lúc, vì bạn sẽ cần nó trong lần thay đổi tồi đầu tiên:
ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201Trên một bộ định tuyến chuyển tiếp cho các máy khác, trước khi đổ lỗi cho bảng, hãy kiểm tra net.ipv6.conf.all.forwarding . Khi chuyển tiếp tắt, các gói gửi tới mạng khác bị bỏ, dù bảng 201 có đúng đến đâu.
Ghi lại thiết kế để người sau có thể kiểm toán
Một bản kiểm kê chỉ lưu fe80::1 sẽ vứt bỏ những trường quan trọng. Ghi điểm đích, chặng kế tiếp, thiết bị, bảng và metric cùng nhau, kèm nguồn gốc của từng tuyến: được quảng cáo, do trình quản lý tạo, hay tĩnh. Khi ai đó sau này hỏi uplink thứ hai có thực sự chở lưu lượng không, bản ghi đó trả lời mà không cần đoán.
Trước khi tuyên bố bảng hoàn tất, xác nhận láng giềng bằng ip -6 neigh show dev uplink0 , đọc lại ip -6 rule show để tìm tai nạn về thứ tự, và thử bằng lưu lượng khớp với quy tắc thay vì một ping đi theo tuyến mặc định. Sau đó cố ý hạ một uplink và xem nhân lùi về tuyến nào; câu trả lời phải khớp với điều bạn đã ghi.