Lối ra IPv6 chết sau khi khởi động lại OpenVPN: kiểm tra quyền sở hữu tiền tố
IPv6 chết sau khi đường hầm được tạo lại. Hãy quyết định ai sở hữu tiền tố được ủy quyền, địa chỉ của máy khách và tuyến đường trả về trước khi khởi động lại bất cứ thứ gì.
IPv6 ngừng truyền lưu lượng ngay tại thời điểm OpenVPN khởi động lại, và IPv4 vẫn tiếp tục hoạt động. Giao diện đường hầm đã được tạo lại, và một thứ khác đang quản lý trạng thái IPv6 của nó đã mất địa chỉ hoặc mất tuyến đường khiến tiền tố có thể đến được. Có ba phần trạng thái riêng biệt tham gia và mỗi phần có một chủ sở hữu khác nhau: tiền tố được ủy quyền của nhà cung cấp và thời hạn của nó, các địa chỉ cấp cho máy khách VPN, và tuyến đường thượng nguồn gửi tiền tố máy khách đó trở lại máy chủ. Xác định chủ sở hữu của từng phần trước khi chạm vào bất kỳ daemon nào, vì khởi động lại sai cái sẽ che giấu vấn đề trong một ngày và đưa nó trở lại ở lần kết nối sau.
Ba phần trạng thái IPv6, ba chủ sở hữu
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Một địa chỉ có phạm vi toàn cầu bên trong đường hầm tự nó không đủ. Các bộ định tuyến thượng nguồn vẫn phải gửi tiền tố đó trở lại máy chủ VPN, và chúng sẽ không làm vậy chỉ vì máy chủ tình cờ có một địa chỉ từ nó.
Đó cũng là lý do việc sao chép một /64 công khai vào bể đường hầm là rủi ro. Một tiền tố được định tuyến tới máy chủ không giống một tiền tố mà phía thượng nguồn coi là on-link, và việc phát hiện láng giềng sẽ không lấp đầy khoảng trống đó.
Đọc trạng thái máy chủ trước khi thay đổi bất cứ điều gì
Ghi lại trạng thái hai lần, một lần khi IPv6 hoạt động và một lần sau khi khởi động lại, rồi so sánh. Các chế độ xem chỉ đọc là đủ, và chúng không tốn gì trong cửa sổ bảo trì:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingTìm ba khác biệt cụ thể: một tuyến đường đã biến mất, một địa chỉ đã chuyển sang thời hạn lỗi thời hoặc không hợp lệ, và một tiền tố đã thay đổi sau khi ủy quyền lại trong khi cấu hình VPN vẫn quảng bá cái cũ.
Nếu địa chỉ biến mất nhưng tiền tố không đổi, daemon cấp địa chỉ đã ngừng quản lý giao diện. Nếu tiền tố thay đổi nhưng địa chỉ không, cấu hình máy khách đã cũ. Hai lỗi trông giống hệt nhau từ trình duyệt và không có điểm gì chung.
Quyết định xem dhcpcd có nên quản lý đường hầm hay không
dhcpcd có thể phát hiện giao diện và ủy quyền các phần của tiền tố DHCPv6 cho các giao diện hạ nguồn, và cấu hình của nó có thể đặt tên rõ ràng cho các mục tiêu ủy quyền. Không có mục tiêu rõ ràng, hành vi được ghi chép của nó có thể liên quan đến các giao diện khác, và đó là cách một đường hầm có được một địa chỉ mà không ai lên kế hoạch.
Hai điều kiện nên đẩy bạn đến chỗ để OpenVPN sở hữu địa chỉ tĩnh của đường hầm: máy chủ đẩy địa chỉ cố định trong cấu hình của nó, và tên đường hầm thay đổi khi kết nối lại. Nếu cả hai đúng, hãy cố ý loại đường hầm khỏi daemon ủy quyền, kèm một chú thích nói rõ lý do.
Nếu thay vào đó việc ủy quyền cho đường hầm là có chủ ý, hãy triển khai việc xử lý thay đổi tiền tố. Điều đó có nghĩa là phản ứng khi tiền tố được ủy quyền hoặc thời hạn của nó thay đổi, cập nhật tiền tố máy khách mà máy chủ quảng bá, và thêm lại tuyến đường. Loại bỏ giao diện trong thiết kế đó sẽ xóa thành phần duy nhất biết về tiền tố mới.
Khởi động lại dhcpcd có vẻ như sửa được mọi thứ vì nó tạo lại trạng thái, nhưng nó cũng gia hạn hoặc thu hồi cấu hình cho những giao diện mà bạn không hề nghĩ tới. Việc khôi phục đó không khiến nó thành bắt buộc sau mỗi lần khởi động lại VPN. Nó cũng đặt lại các bộ đếm mà bạn dùng làm bằng chứng. Hãy ưu tiên tải lại có mục tiêu đúng giao diện mà bạn thực sự đã thay đổi.
Xác thực IPv6 tách biệt với NAT IPv4
Xác nhận rằng chuyển tiếp được bật và tuyến đường thượng nguồn trỏ tới tiền tố máy khách thực tế, rồi thực hiện một kết nối IPv6 được phép mới. Cũng hãy kiểm tra bảng tuyến đường IPv6 của chính máy khách, vì một máy khách hiển thị địa chỉ công khai không chứng minh rằng yêu cầu của nó đã dùng đường hầm.
Việc giả lập IPv4 giải quyết một vấn đề khác: đường trả về cho các nguồn riêng tư. Nó không làm gì cho một tiền tố IPv6 đã bị thu hồi, và thêm nó vào sẽ không mang IPv6 trở lại.
Kết thúc bằng bản ghi quyền sở hữu: thành phần nào ủy quyền tiền tố, thành phần nào cấp địa chỉ máy khách, thành phần nào giữ tuyến đường trả về, và điều gì xảy ra với từng thành phần khi kết nối lại. Bốn dòng trong một runbook giúp người tiếp theo khỏi phải khởi động lại ba daemon để tìm ra cái quan trọng.