Hai chủ sở hữu, một địa chỉ: IP trùng trên cầu TAP

Một máy khách Windows giữ 10.8.0.2 và hoạt động cho đến khi thứ tự khởi động thay đổi; khi đó cùng địa chỉ ấy bị báo là xung đột dù không có gì thay đổi trên máy khách. Một máy chủ thứ hai trong cùng phân đoạn được bắc cầu cũng đòi cùng giá trị, và máy hoàn tất cấu hình sau cùng thường là bên thua. Cả hai đều tin rằng địa chỉ là của mình, và bên thua lặng lẽ ngừng dùng một địa chỉ mà nó được bảo phải dùng. Chính việc coi đây là vấn đề thời điểm khiến nó tái diễn sau mỗi lần khởi động lại.

Đọc bằng chứng xung đột trước khi chạm vào một cầu

Windows báo xung đột địa chỉ cùng với địa chỉ phần cứng của bên đòi còn lại. Địa chỉ phần cứng ấy mới là dữ kiện hữu ích, vì nó ứng với một giao diện trên một máy chủ, trong khi tên hiển thị của sự kiện không cho biết gì về nơi bản trùng nằm. Ghi lại địa chỉ phần cứng trước khi thay đổi bất cứ điều gì.

Việc phát hiện trùng lặp dựa trên ARP thăm dò các chủ sở hữu cạnh tranh trước khi một địa chỉ được dùng và tiếp tục theo dõi sau đó. Vì thế một máy chủ vắng mặt trong lúc bạn cấu hình mạng vẫn có thể gây xung đột một giờ sau. Việc thăm dò không phải kiểm tra một lần lúc khởi động. Một máy xuất hiện sau đó có thể lấy một địa chỉ đã được dùng yên ổn cả ngày, và đó là lý do sự cố đọc như một cuộc đua chứ không phải lỗi cấu hình.

Bản thân sự kiện xung đột không cho biết cấu hình nào đã tạo ra yêu sách kia, và việc xóa địa chỉ để thử nghiệm phá hủy ánh xạ lẽ ra đã cho bạn biết điều đó. Mục đích của bằng chứng là biến một địa chỉ phần cứng thành giao diện mà bạn có thể kiểm tra. Tra cứu tồn kho theo tên máy thường đưa bạn đến máy chủ sai.

Lập danh mục mọi yêu sách trong phân đoạn

Một thiết lập TAP được bắc cầu nối những phân đoạn Ethernet trước đây tách rời, nên những địa chỉ vốn duy nhất trong mạng riêng của chúng có thể đụng nhau ngay khi các khung dùng chung một liên kết. Đó là lý do nhóm lỗi này tồn tại trên VPN và không tồn tại trên các mạng có định tuyến mà nó thay thế. Liệt kê mọi chủ sở hữu khả dĩ thay vì chủ sở hữu đầu tiên bạn nghi ngờ.

Đi qua danh sách theo thứ tự này: các địa chỉ trên mỗi thiết bị cầu và các cổng thành viên của nó, bể OpenVPN và mọi gán cố định cho từng máy khách, cùng mọi máy chủ DHCP bao phủ phân đoạn được bắc cầu. Sau đó đối chiếu địa chỉ phần cứng từ báo cáo xung đột với các giao diện bạn tìm được.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

Bể địa chỉ và dải DHCP là hai chủ sở hữu mà người ta hay quên. In cả hai dải cùng nhau và tìm chỗ chồng lấn trước khi làm bất cứ việc gì khác. Một địa chỉ cầu được gán tay và một bể cấp cùng giá trị sẽ đụng nhau sớm muộn, và va chạm trông ngẫu nhiên cho đến khi cả hai dải được in cạnh nhau.

Chỉ đánh số cầu ở nơi chúng cần một danh tính

Trong một cầu máy chủ thông thường, thiết bị cầu mang cấu hình lớp ba của máy chủ và các thành viên Ethernet cùng TAP đóng vai trò cổng. Gán cho mỗi thành viên địa chỉ riêng, hoặc sao chép một kịch bản cài đặt sang nhiều máy mà không đổi địa chỉ, là cách một phân đoạn duy nhất rốt cuộc có ba chủ sở hữu cùng một giá trị. Các thành viên không cần danh tính riêng để chuyển tiếp khung. Chúng cần đúng một danh tính cho mỗi máy chủ phải được tiếp cận trong phân đoạn đó.

Một cầu chỉ chuyển mạch khung hoàn toàn không cần địa chỉ trong phân đoạn đó. Để nó không có số sẽ loại bỏ cả một nhóm va chạm, với điều kiện máy chủ vẫn có một đường quản trị mà bạn đã kiểm chứng. Xác nhận truy cập trước, gỡ địa chỉ thứ hai, và kiểm tra khả năng tiếp cận thứ ba.

Nếu địa chỉ bạn sắp xóa là đường duy nhất vào máy, xóa nó như một thử nghiệm là sự cố tự gây ra chứ không phải chẩn đoán. Kiểm chứng đường ngoài băng trước khi thử bất cứ điều gì.

Làm cho bản sửa sống sót qua lần khởi động lại

Thay đổi một giao diện đang chạy chỉ sửa lần khởi động hiện tại và không gì khác. Bất cứ thứ gì tạo lại địa chỉ lúc khởi động sẽ khôi phục xung đột ở lần khởi động lại sau, và bạn sẽ kết luận rằng bản sửa không hiệu quả trong khi thực ra nó chưa bao giờ bền vững. Ghi lại bạn đã đổi tệp nào, để lần khởi động lại sau xác nhận một quyết định thay vì bộc lộ một bất ngờ.

Tìm chủ sở hữu của cấu hình đó: một hồ sơ trình quản lý mạng, một tệp cho mỗi giao diện, một định nghĩa container hoặc VM, hay một đoạn cloud-init. Sửa nó ở đó, rồi cố ý khởi động lại một máy chủ bị ảnh hưởng để xác nhận rằng giá trị mới là thứ quay về. Khởi động lại là phép thử duy nhất chứng minh tính bền vững.

Dành riêng các địa chỉ cầu bên trong dải DHCP làm ngoại lệ, hoặc chuyển chúng ra ngoài. Một đăng ký chỉ tồn tại trong bảng tính không phải là ngoại lệ, và bộ cấp phát sẽ không đọc nó.

Chứng minh điều đó khi mọi máy khách đều trực tuyến

Một kết nối thành công không chứng minh gì, vì triệu chứng ban đầu chỉ xuất hiện khi thứ tự thay đổi. Khởi động mọi máy khách dự kiến, thay đổi thứ tự khởi động, và lặp lại sau khi kết nối lại. Sau đó khởi động lại máy chủ từng thua cuộc đua và xác nhận địa chỉ vẫn tồn tại.

Để xác nhận trực tiếp, hãy thăm dò xem có chủ sở hữu trùng trước khi gán địa chỉ và theo dõi bảng láng giềng sau đó. Nếu không có gì trả lời lần thăm dò và địa chỉ vẫn được sở hữu duy nhất qua một chu trình khởi động lại trọn vẹn, xung đột đã được giải quyết chứ không chỉ bị che giấu. Các lệnh bên dưới thực hiện cả hai phép kiểm tra trên thiết bị cầu. RFC 5227 mô tả hành vi thăm dò và thông báo mà các công cụ này thực thi, và đó là nguồn cần trích dẫn khi ai đó đề nghị tắt hẳn việc phát hiện.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

Một lần thăm dò không nhận được trả lời là kết quả mong đợi trên một phân đoạn sạch. Một lần thăm dò có phản hồi cho bạn địa chỉ phần cứng của chủ sở hữu còn lại, cùng bằng chứng mà sự kiện Windows đã cho bạn lúc đầu. Hãy giữ kết quả đó cùng hồ sơ thay đổi, vì nó là bằng chứng duy nhất rằng địa chỉ được giữ duy nhất.