Điểm:0

Không thể gán địa chỉ IP tĩnh đã sử dụng trước đó cho máy khách OpenVPN

lá cờ ng

Chúng tôi có một máy chủ OpenVPN với server.conf sau:

cục bộ x.x.x.x
cổng 1194
nguyên tcp
tập phát triển
ca ca.crt
máy chủ chứng chỉ.crt
máy chủ khóa.key
dh dh.pem
xác thực SHA512
tls-crypt tc.key
mạng con cấu trúc liên kết
máy chủ 10.8.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
khách hàng đến khách hàng
lưu giữ 10 120
mật mã AES-256-CBC
người dùng không ai
nhóm không có nhóm
phím kiên trì
kiên trì điều chỉnh
trạng thái openvpn-status.log
động từ 3
crl-xác minh crl.pem

Chúng tôi cũng có một phiên bản Linux trong AWS chạy ứng dụng khách OpenVPN và chúng tôi đã chỉ định thành công địa chỉ IP tĩnh 10.8.0.2 cho phiên bản đó bằng cách thêm một tệp có tên chung của ứng dụng khách vào máy chủ OpenVPN /etc/openvpn/ccd thư mục với nội dung sau:

ifconfig-push 10.8.0.2 255.255.0.0

Bây giờ, chúng tôi muốn thay thế phiên bản Linux đó bằng phiên bản Windows Server 2019 và cung cấp cho nó cùng một địa chỉ IP tĩnh 10.8.0.2. Vì vậy, chúng tôi đã làm như sau:

  • đã xóa phiên bản Linux trong AWS
  • đã sử dụng Nyr OpenVPN tập lệnh openvpn-install.sh trên máy chủ OpenVPN để thu hồi máy khách Linux
  • đã xóa máy khách Linux khỏi máy chủ OpenVPN /etc/openvpn/server/easy-rsa/pki/index.txt tập tin
  • đã xóa chứng chỉ của máy khách Linux khỏi máy chủ OpenVPN /etc/openvpn/server/easy-rsa/pki/revoked/certs_by_serial danh mục
  • đã xóa tệp máy khách Linux trong máy chủ OpenVPN /etc/openvpn/ccd danh mục
  • đã xóa máy chủ OpenVPN /etc/openvpn/server/ipp.txt tệp (vì nó có liên kết 10.8.0.2 với máy khách Linux)
  • đã thêm một tệp mới vào máy chủ OpenVPN /etc/openvpn/ccd thư mục cho phiên bản Windows Server 2019 với ifconfig-push 10.8.0.2 255.255.0.0
  • đã tạo phiên bản Windows Server 2019 trong AWS
  • Cài đặt OpenVPN 2.4.9 trên phiên bản Windows Server 2019

Phiên bản Windows Server 2019 có tệp cấu hình máy khách OpenVPN sau:

khách hàng
tập phát triển
nguyên tcp
từ xa x.x.x.x 1194
giải quyết-thử lại vô hạn
quý tộc
phím kiên trì
kiên trì điều chỉnh
máy chủ từ xa-cert-tls
xác thực SHA512
mật mã AES-256-CBC
bỏ qua-unknown-option khối-bên ngoài-dns
khối-bên ngoài-dns
động từ 3

Khi chúng tôi khởi động ứng dụng khách OpenVPN trên phiên bản Windows Server 2019, thông tin sau sẽ hiển thị trong tệp nhật ký ứng dụng khách OpenVPN:

Thứ tư ngày 14 tháng 7 01:15:02 năm 2021 [máy chủ] Bắt đầu kết nối ngang hàng với [AF_INET]x.x.x.x:1194
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 KIỂM SOÁT ĐÃ GỬI [máy chủ]: 'PUSH_REQUEST' (trạng thái=1)
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 PUSH: Đã nhận thông báo điều khiển: 'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.0.0,peer-id 0,cipher AES-256 -GCM'
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 NHẬP TÙY CHỌN: bộ hẹn giờ và/hoặc thời gian chờ đã sửa đổi
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 NHẬP TÙY CHỌN: --ifconfig/up tùy chọn đã sửa đổi
Thứ tư ngày 14 tháng 7 01:15:03 2021 NHẬP TÙY CHỌN: các tùy chọn liên quan đến tuyến đường được sửa đổi
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 NHẬP TÙY CHỌN: bộ id ngang hàng
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 NHẬP TÙY CHỌN: điều chỉnh link_mtu thành 1658
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 NHẬP TÙY CHỌN: kênh dữ liệu tùy chọn tiền điện tử đã sửa đổi
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 Kênh dữ liệu: sử dụng mật mã đã thương lượng 'AES-256-GCM'
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 Kênh dữ liệu gửi đi: Khởi tạo mật mã 'AES-256-GCM' bằng khóa 256 bit
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 Kênh dữ liệu đến: Khởi tạo mật mã 'AES-256-GCM' bằng khóa 256 bit
Thứ tư ngày 14 tháng 7 01:15:03 Dịch vụ tương tác năm 2021 msg_channel=0
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 open_tun
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 Thiết bị TAP-WIN32 [Kết nối khu vực cục bộ] đã mở: \.\Global\{526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}.tap
Thứ tư ngày 14 tháng 7 01:15:03 2021 Trình điều khiển TAP-Windows Phiên bản 9.24 
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 Trình điều khiển TAP-Windows đã thông báo để đặt IP/mặt nạ mạng DHCP là 10.8.0.2/255.255.0.0 trên giao diện {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F} [DHCP-serv: 10.8.0.0 , thời gian thuê: 31536000]
Thứ tư ngày 14 tháng 7 01:15:03 Năm 2021 ARP Flush thành công trên giao diện [11] {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}
Thứ tư ngày 14 tháng 7 01:15:03 2021 Block_DNS: Công cụ WFP đã mở
Thứ tư ngày 14 tháng 7 01:15:03 2021 Block_DNS: Sử dụng lớp con hiện có
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 Block_DNS: Đã thêm bộ lọc giấy phép cho exe_path
Thứ tư ngày 14 tháng 7 01:15:03 2021 Block_DNS: Đã thêm bộ lọc khối cho tất cả các giao diện
Thứ tư ngày 14 tháng 7 01:15:03 năm 2021 Block_DNS: Đã thêm bộ lọc giấy phép cho giao diện TAP
Thứ tư ngày 14 tháng 7 01:15:08 2021 CÁC TUYẾN KIỂM TRA: 0/0 đã thành công len=-1 ret=0 a=0 u/d=down
Thứ tư ngày 14 tháng 7 01:15:08 2021 Lộ trình: Chờ giao diện TUN/TAP xuất hiện...
Thứ tư ngày 14 tháng 7 01:15:13 2021 CÁC TUYẾN KIỂM TRA: 0/0 đã thành công len=-1 ret=0 a=0 u/d=down
Thứ tư ngày 14 tháng 7 01:15:13 2021 Lộ trình: Chờ giao diện TUN/TAP xuất hiện...
Thứ tư ngày 14 tháng 7 01:15:14 2021 CÁC TUYẾN KIỂM TRA: 0/0 đã thành công len=-1 ret=0 a=0 u/d=down
Thứ tư ngày 14 tháng 7 01:15:14 2021 Lộ trình: Chờ giao diện TUN/TAP xuất hiện...
Thứ tư ngày 14 tháng 7 01:15:15 2021 CÁC TUYẾN KIỂM TRA: 0/0 đã thành công len=-1 ret=0 a=0 u/d=down
Thứ tư ngày 14 tháng 7 01:15:15 2021 Lộ trình: Chờ giao diện TUN/TAP xuất hiện...
Thứ tư ngày 14 tháng 7 01:15:16 2021 CÁC TUYẾN KIỂM TRA: 0/0 đã thành công len=-1 ret=0 a=0 u/d=down
Thứ tư ngày 14 tháng 7 01:15:16 2021 Lộ trình: Chờ giao diện TUN/TAP xuất hiện...
Thứ tư ngày 14 tháng 7 01:15:17 2021 CÁC TUYẾN KIỂM TRA: 0/0 đã thành công len=-1 ret=0 a=0 u/d=down
Thứ tư ngày 14 tháng 7 01:15:17 2021 Lộ trình: Chờ giao diện TUN/TAP xuất hiện...
Thứ tư ngày 14 tháng 7 01:15:18 2021 CÁC TUYẾN KIỂM TRA: 0/0 đã thành công len=0 ret=1 a=0 u/d=up
Thứ tư ngày 14 tháng 7 01:15:18 năm 2021 CẢNH BÁO: cấu hình này có thể lưu mật khẩu vào bộ nhớ cache -- sử dụng tùy chọn auth-nocache để ngăn điều này
Thứ tư ngày 14 tháng 7 01:15:18 2021 Trình tự khởi tạo đã hoàn thành

Như bạn có thể thấy, ứng dụng khách OpenVPN trên phiên bản Windows Server 2019 đang nhận địa chỉ IP 10.8.0.2 từ máy chủ OpenVPN. Tuy nhiên, tôi liên tục chạy ipconfig trong cửa sổ dòng lệnh và tôi thấy điều sau đây xảy ra cứ sau 15 giây:

  • Bộ điều hợp mạng OpenVPN (được gọi là "TAP-Windows Adapter V9") nhận địa chỉ IP là 169.254.211.103 trong vài giây.
  • Sau đó, bộ điều hợp mạng OpenVPN nhận địa chỉ IP là 10.8.0.2 trong khoảng một giây. Trong một giây này, lệnh ping 10.8.0.1 (máy chủ OpenVPN) sẽ thành công. Ngoài một giây đó, ping 10.8.0.1 sẽ không thành công.
  • Sau đó, bộ điều hợp mạng OpenVPN sẽ mất địa chỉ IP 10.8.0.2 và không có bất kỳ địa chỉ IP nào trong ~12 giây tiếp theo.
  • Quá trình nhận địa chỉ 169.254.x.x, sau đó nhận và mất địa chỉ 10.8.0.2 cứ lặp lại sau mỗi 15 giây.

Sau đó, tôi quyết định xem điều gì sẽ xảy ra nếu tôi cố gắng cung cấp cho Windows Server 2019 một địa chỉ IP tĩnh khác chưa từng được sử dụng trước đây. Tôi đã sửa đổi tệp cho Windows Server 2019 trong máy chủ OpenVPN /etc/openvpn/ccd thư mục để cung cấp cho nó một địa chỉ IP tĩnh là 10.8.0.11:

ifconfig-push 10.8.0.11 255.255.0.0

Sau đó, tôi đã khởi động lại ứng dụng khách OpenVPN trên phiên bản Windows Server 2019 và nó đã hoạt động! Máy khách đang sử dụng thành công địa chỉ IP 10.8.0.11 và hoàn toàn không bị mất địa chỉ này.

Vậy tại sao phiên bản Windows Server 2019 tiếp tục mất địa chỉ 10.8.0.2, địa chỉ đã được máy khách Linux sử dụng trước đó? Như bạn có thể thấy từ các bước tôi liệt kê ở trên, tôi đã thu hồi máy khách Linux khỏi máy chủ OpenVPN và tôi đã xóa tất cả dấu vết về tên chung của máy khách Linux mà tôi có thể tìm thấy trên máy chủ OpenVPN.

Chúng tôi muốn phiên bản Windows Server 2019 sử dụng địa chỉ 10.8.0.2 hơn vì chúng tôi đã viết các tập lệnh giả sử 10.8.0.2 sẽ là IP tĩnh và đã gửi các tập lệnh đó cho bên thứ ba. Sẽ dễ dàng hơn nếu có thể gắn bó với 10.8.0.2.

CẬP NHẬT:

Tôi đã không xem xét phiên bản Windows Server 2019 trong vài ngày và bây giờ tôi mới xem xét lại. Đáng ngạc nhiên là nó có địa chỉ IP 10.8.0.2 và nó không bao giờ biến mất. Mọi thứ đã hoạt động như mong đợi. Tôi không chắc tại sao, vì tôi đã không thay đổi bất cứ điều gì.

Vì vậy, tôi đã khởi động lại ứng dụng khách OpenVPN trên phiên bản Windows Server 2019 để xem điều gì sẽ xảy ra và bây giờ nó quay lại hành vi nhận địa chỉ 169.254.x.x, sau đó nhận và mất địa chỉ 10.8.0.2 cứ sau 15 giây.

Điểm:0
lá cờ ng

Đó là xung đột địa chỉ IP, như được chỉ ra trong nhật ký sự kiện hệ thống trên phiên bản Windows Server 2019.

Chúng tôi có thêm một số máy chủ Linux chạy ứng dụng khách OpenVPN (khác với ứng dụng khách Linux mà tôi đã đề cập trong câu hỏi). Mỗi máy chủ Linux này có một cầu nối được thiết lập với địa chỉ IP 10.8.0.2. Cây cầu này kết nối giao diện tap0 của máy khách OpenVPN với giao diện eth1 được gắn vào thiết bị của nhà cung cấp. Thiết lập này cho phép phần mềm của nhà cung cấp chạy trên phiên bản Windows Server 2019 kết nối với thiết bị.

Tôi đã tắt máy chủ Linux và khởi động lại phiên bản Windows Server 2019. Phiên bản Windows Server 2019 có thể nhận được 10.8.0.2 mà không bị mất. Sau đó, tôi đã khởi động các máy chủ Linux và mọi thứ hiện đang hoạt động tốt. Các phiên bản Windows Server 2019 và Linux rất hài lòng và phần mềm chạy trên Windows Server có thể kết nối với các thiết bị được gắn vào máy chủ Linux thông qua OpenVPN.

Vì vậy, giải pháp là chỉ cần đảm bảo phiên bản Windows Server 2019 khởi động trước khi bất kỳ phiên bản Linux nào thiết lập cầu nối của chúng.

Chỉnh sửa: Một giải pháp dễ dàng hơn là chỉ cần khởi động lại máy chủ OpenVPN rồi khởi động ngay ứng dụng khách OpenVPN trên phiên bản Windows Server 2019. Nó sẽ nhận được 10.8.0.2 trước khi bất kỳ phiên bản Linux nào có thể kết nối lại với máy chủ OpenVPN.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.