Máy ảo Vagrant biến mất khi VPN kết nối: tuyến đường hỏng là của ai

Máy trả lời cách đây một phút, VPN kết nối, và giờ cùng địa chỉ đó hết thời gian chờ. Ba lỗi tạo ra triệu chứng này, và chúng nằm trên những máy khác nhau. Máy chủ có thể mất tuyến đường tới mạng riêng, dải NAT của máy khách có thể đụng với dải mà đường hầm đang quảng bá, hoặc một đường hầm đầy đủ có thể chiếm quyền sở hữu mọi tuyến đường trên máy chủ. Hãy tìm ra lỗi nào đã xảy ra trước khi đổi bất kỳ cấu hình nào, vì mỗi cách sửa nằm ở một nơi khác.

Nhìn tuyến đường, không nhìn cái máy

Hãy xem quyết định định tuyến của máy chủ cho địa chỉ máy khách khi đường hầm đang bật. Tuyến đường vẫn trỏ tới card chỉ-máy-chủ không phải vấn đề. Tuyến đường giờ trỏ tới card VPN mới là vấn đề, và ứng dụng khách đã đổi nó, không phải bạn. Việc card giữ nguyên địa chỉ cho biết giao diện vẫn sống, một sự thật khác với việc tuyến đường còn sống.

Phiên SSH rớt đúng lúc kết nối là hành vi đã dự kiến. Ứng dụng khách tái sử dụng card và cài tuyến đường, nên kết nối chết vài giây. Lỗi là kết nối không bao giờ trở lại, không phải cái chỉ nhấp nháy.

Chụp bảng trước đường hầm và một lần nữa sau đó, rồi so sánh hai đầu ra ấy. Khác biệt chính là chẩn đoán, và nó cũng là bằng chứng mà chủ mạng sẽ yêu cầu.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Đọc bảng của máy chủ trước và sau

Trên Linux, mức ưu tiên giữa các tuyến đường chồng lấn đến từ độ dài tiền tố và metric, nên tuyến VPN cụ thể hơn thắng kể cả khi sai. Trên Windows, metric giao diện quyết định thế hòa, và card đường hầm thường đến với metric thấp hơn card ảo. Cả hai trường hợp triệu chứng nhìn thấy đều giống nhau: gói tin ra khỏi card đường hầm và biến mất.

In các card và metric của chúng bên cạnh tuyến đường cho tiền tố máy khách. Cặp đầu ra đó trả lời câu hỏi sở hữu chỉ bằng một cái nhìn.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Nếu tuyến đường đổi mà metric của card không đổi, ứng dụng khách đã cài một tuyến cạnh tranh. Nếu metric đổi, ứng dụng khách đã sắp xếp lại các card. Cả hai đều sửa được, và được sửa ở hai nơi khác nhau.

Khi dải NAT của máy khách chính là va chạm

VirtualBox NAT mặc định dùng 10.0.2.0/24, và một đường hầm đẩy cùng dải ấy khiến máy khách gửi lưu lượng đó tới cổng NAT của mình thay vì tới đích thật. Gói tin không bao giờ rời máy chủ, nên không nhật ký tường lửa nào ở phía bên kia hiển thị nó. Docker Machine cũng có cùng loại xung đột trong gói chỉ-máy-chủ của nó, và đổi gói đó có thể đòi hỏi tạo lại máy cùng các chứng chỉ của nó.

Chọn phương án thay thế bằng cách liệt kê những gì đường hầm đã quảng bá, rồi những gì mạng văn phòng dùng, rồi những gì mỗi card ảo trên máy chủ này đã đòi. Chính sự chồng lấn làm hỏng định tuyến, còn giống nhau thì không liên quan. Một dải có thể nằm trọn bên trong dải khác mà thoạt nhìn không giống chút nào.

Đặt dải mới khi tạo máy, hoặc đổi rồi nạp lại, sau đó thử lại kết nối hỏng từ máy khách. Bảng của chính máy khách mới là góc nhìn quan trọng.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Khôi phục tuyến đường mà không đánh nhau với ứng dụng khách

Mỗi nền tảng đều có cách đưa tiền tố chỉ-máy-chủ lên trước. Trên macOS, tuyến tĩnh tới giao diện chỉ-máy-chủ hoạt động đến lần kết nối kế tiếp. Trên Windows, metric giao diện thấp hơn trên card ảo giữ nó được ưu tiên. Trên Linux, thao tác thay thế bao trùm một tiền tố. Cả ba đều là cách lách, vì ứng dụng khách khẳng định lại tuyến của nó sẽ hủy chúng.

Hãy viết kiểm tra thành script thay vì kết nối lại mù quáng lúc khởi động. Một script nhỏ in tuyến đường cho tiền tố máy khách sau mỗi lần kết nối biến điều bí ẩn thành một dòng trong nhật ký.

Nếu hồ sơ là đường hầm đầy đủ, hãy đề nghị chủ mạng cho đường hầm chia tách hoặc một ngoại lệ có văn bản. Âm thầm thêm tuyến vòng qua chính sách bảo mật không phải là sửa chữa, mà là vấn đề thứ hai đến sau với một kiểm toán viên.

Kiểm tra cách sửa ở cả hai phía

Sau khi đổi, xác minh ba tuyến: máy chủ tới máy khách, máy khách tới máy chủ doanh nghiệp và máy khách tới internet. Một cách sửa khôi phục cái này và phá cái kia là thay đổi cấu hình khoác áo sửa chữa. Chụp đúng những đầu ra đã thu trước khi đổi để so sánh ngang bằng.

Ghi lại giao diện, metric và tuyến đường đã đổi, kèm thời điểm, để lần sau là tra cứu chứ không phải dựng lại. Ghi chú đó đáng giá hơn một chuỗi phiếu dài.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Khi máy chủ tới được máy khách trở lại và máy khách tới được LAN, bạn đã khôi phục tuyến đường ban đầu. Khi chỉ một trong hai hoạt động, lỗi còn lại nằm ở địa hạt của chủ kia, và khác biệt cho bạn biết đó là địa hạt nào.