Bộ điều hợp OpenVPN nhảy liên tục trên Windows? Hãy kiểm tra IP bị trùng

Trên Windows, một bộ điều hợp OpenVPN nhận địa chỉ, bỏ nó rồi lặp lại vài giây một lần thường không phải lỗi DHCP. Bộ điều hợp đang được yêu cầu dùng một địa chỉ mà thứ khác đã trả lời, nên Windows đánh dấu nó không dùng được và máy khách bắt đầu lại. Nhật ký máy khách im lặng vì xung đột được giải quyết ở tầng dưới, bên trong ngăn xếp mạng của chính hệ điều hành.

Sự khác biệt đó quan trọng, vì mọi bước xử lý sự cố nhắm vào cấu hình đường hầm sẽ bỏ sót một địa chỉ trùng ở phía máy chủ.

Bắt đầu từ nhật ký sự kiện Windows, không phải nhật ký máy khách

Windows ghi các xung đột địa chỉ vào nhật ký System với mã sự kiện 4198 và 4199. Mã đầu báo một xung đột được phát hiện cho một địa chỉ, mã thứ hai báo rằng một giao diện không thể dùng địa chỉ mà nó được cấu hình. Cả hai đều không nhắc đến OpenVPN, đó chính là lý do chúng dễ bị bỏ qua.

Lấy các sự kiện gần đây và so sánh dấu thời gian của chúng với chu kỳ gia hạn của bộ điều hợp: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Xung đột mỗi mười lăm giây khớp với một máy khách đang thử lại cùng địa chỉ với chủ sở hữu vẫn trả lời cho nó. Một xung đột duy nhất lúc kết nối lại chỉ ra một va chạm một lần. Dù thế nào, câu hỏi tiếp theo là ai khác đang giữ địa chỉ.

Ba cách bố trí đặt hai máy chủ lên một địa chỉ

Hỏi máy chủ xem nó nghĩ ai đang giữ địa chỉ, rồi hỏi mạng xem ai trả lời địa chỉ đó. grep -H ifconfig-push /etc/openvpn/ccd/* liệt kê từng địa chỉ đường hầm được ghim và chứng chỉ mà nó thuộc về. ip -4 neigh show dev tap0 cho thấy cầu đã học được gì ở lớp hai. So sánh hai danh sách đó tìm ra hầu hết các địa chỉ trùng trong chưa đầy một phút.

Ba cách bố trí giải thích gần như tất cả: một mục client-config-dir ghim một địa chỉ cho hai chứng chỉ, một phân đoạn tap được cầu nối cấp cho máy một địa chỉ mà máy chủ khác đã có tĩnh, hoặc một tệp thuê cũ trả về địa chỉ mà một máy khách vẫn đang kết nối tin là của mình. Trường hợp thứ ba là khó lường nhất, vì ifconfig-pool-persist cố ý dùng lại địa chỉ cho những máy khách đã biết.

Hãy làm địa chỉ trở nên duy nhất thay vì chạy đua giành nó

Thứ tự khởi động chỉ quyết định ai thắng hôm nay, nên hãy coi mọi bản sửa dựa trên trình tự khởi động lại là tạm thời. Cấp cho mỗi máy khách dòng ifconfig-push riêng, hoặc cấp địa chỉ tĩnh từ một dải mà không cầu hay giao diện máy chủ nào chạm tới. Cũng hãy rà soát danh sách máy khách để tìm tên chung trùng, vì duplicate-cn cho phép hai phiên dùng chung một danh tính và do đó dùng chung một địa chỉ được ghim. Nếu một thiết bị đã cầu nối thực sự cần địa chỉ cố định, hãy chuyển nó sang mạng con riêng hoặc giữ chỗ từ pool ở nơi máy chủ ghi lại.

Chỉ xóa tệp persist sau khi bạn biết nó chứa những hợp đồng thuê nào, nếu không lần kết nối lại tiếp theo sẽ lại cấp đúng những địa chỉ đó.

Khởi động lại đúng thứ tự và xác nhận mỗi địa chỉ chỉ có một chủ sở hữu

Áp dụng thay đổi trên máy chủ trước, rồi kết nối lại các máy khách, để mọi bên tham gia đăng ký với pool đã sửa. Khởi động lại máy khách trước sẽ khiến chúng giữ địa chỉ mà máy chủ vẫn tin là đã có người dùng. Sau khi khởi động lại, đọc tệp trạng thái và xác nhận mỗi tên chung xuất hiện một lần với một địa chỉ. Hai mục cho một tên nghĩa là phiên cũ chưa bao giờ đóng, chứ không phải pool bị hỏng.

Nếu máy khách vẫn không giữ được địa chỉ, hãy kiểm tra xem một giao diện cầu trên cùng máy chủ có mang địa chỉ đó không. Một cầu thừa hưởng địa chỉ từ thiết bị nhà cung cấp sẽ trả lời ARP cho nó ngay cả khi máy chủ VPN đã giao địa chỉ đó cho một máy khách.

Hãy theo dõi vượt qua một chu kỳ gia hạn đầy đủ trước khi đóng phiếu yêu cầu

Một lần đọc sạch không chứng minh được gì. Hãy theo dõi bộ điều hợp ít nhất mười phút và buộc kết nối lại ở giữa: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Địa chỉ phải tồn tại qua lần kết nối lại và vẫn ở trạng thái ưu tiên.

Sau đó chạy lại truy vấn sự kiện từ bước đầu tiên và xác nhận nó không trả về gì mới. Một nhật ký im lặng qua lần kết nối lại là bằng chứng xung đột đã biến mất, trong khi nhật ký im lặng sau một lần kết nối chỉ có nghĩa là cuộc đua chưa xảy ra. Cuối cùng, hãy kiểm tra tài nguyên mà đường hầm tồn tại vì nó, vì một cầu đã mất địa chỉ có thể làm hỏng đường dẫn của nhà cung cấp trong khi bản thân VPN trông vẫn khỏe.

Ghi lại dải pool, từng địa chỉ được ghim và máy chủ sở hữu nó trong ghi chú máy chủ. Khi đó lần va chạm tiếp theo chỉ mất vài phút để phát hiện thay vì cả buổi chiều để tìm lại.