Điểm:2

Cách truy cập dịch vụ chạy trên máy chủ từ WSL2 (kết nối bị từ chối)

lá cờ cn

Tôi có Selenium đang chạy trên máy chủ của mình và ứng dụng của tôi nằm trong vùng chứa docker (bên trong WSL2).

Tôi đang cố gắng kết nối ứng dụng với selen, ứng dụng đang nghe trên cổng 4445. Nó đã từng hoạt động cách đây vài tháng, tôi nghĩ có điều gì đó đã thay đổi trong WSL.

Máy chủ đang nghe trên 4445:

tái bút> netstat -ano | phát hiệntr :4445
  TCP 0.0.0.0:4445 0.0.0.0:0 NGHE 11604
  TCP [::]:4445 [::]:0 NGHE 11604

Tôi có thể truy cập Selenium từ máy chủ Windows:

>curl -X POST http://DESKTOP-HED9HVG:4445/wd/hub
{"tiểu bang":".....}

nhưng không phải từ WSL2:

$ curl -X POST http://172.22.241.214:4445/wd/hub
curl: (7) Không thể kết nối với cổng 172.22.241.214 4445: Kết nối bị từ chối

Tôi đã thử một số tùy chọn cho ip mà tôi đã sử dụng trong curl:

  • địa chỉ ip ip eth0
  • $(tên máy chủ)
  • địa chỉ ip từ kết quả của ipconfig/tất cả | phát hiện IPv4
  • kết quả địa chỉ ip của lộ trình -n | grep UG | đầu -n1 | awk '{in $2}'

Tôi đã cài đặt tcptraeroute trên WSL và chạy nó. Đây là đầu ra:

$ tcptraroute $(tên máy chủ) 4445
Lo thiết bị đã chọn, địa chỉ 127.0.0.1, cổng 53915 cho các gói gửi đi
Truy tìm đường dẫn tới DESKTOP-WXYZ1 (127.0.1.1) trên cổng TCP 4445, tối đa 30 bước nhảy
 1 DESKTOP-WXYZ1.localdomain (127.0.1.1) [đã đóng] 0,075 ms 0,082 ms 0,074 ms

Nhân tiện, ping từ WSL đến máy chủ hoạt động:

$ ping $(tên máy chủ)
PING DESKTOP-WXYZ1.localdomain (127.0.1.1) 56(84) byte dữ liệu.
64 byte từ DESKTOP-WXYZ1.localdomain (127.0.1.1): icmp_seq=1 ttl=64 time=0,053 ms

Tôi đã cố gắng tắt hoàn toàn tường lửa của windows nhưng không được. Tôi cũng đã thêm một quy tắc trong "Tường lửa của Bộ bảo vệ Windows" để bật cụ thể cổng 4445. Nó vẫn không giúp được gì

Thông tin về WSL:

> wsl -l -v
  TÊN TIỂU BANG PHIÊN BẢN
* Ubuntu-20.04 Chạy 2
  docker-desktop Đang chạy 2
  docker-desktop-data Đang chạy 2

Bất cứ ý tưởng làm thế nào để giải quyết điều này?

Điểm:2
lá cờ jp

Xem hướng dẫn tại đây

https://docs.microsoft.com/en-us/windows/wsl/networking#accessing-windows-networking-apps-from-linux-host-ip

Nếu bạn muốn truy cập ứng dụng mạng chạy trên Windows (ví dụ: ứng dụng chạy trên máy chủ NodeJS hoặc SQL) từ bản phân phối Linux của bạn (tức là Ubuntu), thì bạn cần sử dụng địa chỉ IP của máy chủ của mình. Mặc dù đây không phải là một trường hợp phổ biến nhưng bạn có thể làm theo các bước sau để nó hoạt động.

Lấy địa chỉ IP của máy chủ của bạn bằng cách chạy lệnh này từ bản phân phối Linux của bạn: con mèo /etc/resolv.conf Copy địa chỉ IP theo cụm từ: nameserver. Kết nối với bất kỳ máy chủ Windows nào bằng địa chỉ IP đã sao chép. Hình dưới đây cho thấy một ví dụ về điều này bằng cách kết nối với máy chủ Node.js đang chạy trong Windows thông qua curl.

Bạn cũng sẽ cần cho phép các kết nối gửi đến cổng đó trong máy chủ. (Thông qua quy tắc tường lửa).

lá cờ cn
Có một nhược điểm với điều này. Nếu bạn đang chạy docker daemon trên wsl, thì máy chủ tên resolv.conf rõ ràng sẽ trỏ đến cổng wsl trong wsl chứ không phải ip máy chủ lưu trữ thực tế của windows.
lá cờ jp
Bạn vẫn có thể chạy các dịch vụ của mình trên máy chủ và các yêu cầu từ bên trong WSL sẽ được chuyển đến chúng.
lá cờ cn
Làm thế nào bạn sẽ truy cập chúng? Tôi giả sử thông qua host.docker.internal? Đó là máy tính để bàn docker cụ thể và ngay cả khi nó không (sử dụng giải pháp thay thế cổng máy chủ), thì nó sẽ tìm kiếm các dịch vụ trên WSL với tư cách là máy chủ lưu trữ cho daemon, chứ không phải các dịch vụ chạy trên windows.
lá cờ jp
Bạn có thể truy cập chúng thông qua IP trực tiếp. Mục nhập dns là `tên máy chủ` của máy chủ lưu trữ. IP đó hiển thị các dịch vụ trên máy chủ Windows chứ không phải WSL. Dù sao thì điều này cũng không liên quan/cụ thể đối với docker. Bạn đang cố truy cập một dịch vụ trên máy chủ lưu trữ từ bên trong vùng chứa?
lá cờ cn
Tôi nghĩ rằng bạn đóng đinh các thông tin sai lệch. Tôi đang nói về việc truy cập các dịch vụ windows từ một vùng chứa chạy trên trình nền được lưu trữ trên wsl. các yêu cầu wsl sẽ chuyển sang dịch vụ windows, các yêu cầu vùng chứa sẽ tìm kiếm các dịch vụ trên wsl là những gì tôi đã gặp phải.
Điểm:0
lá cờ cn

Tôi thực sự đã gặp phải vấn đề này trong một dự án mà tôi đang thực hiện cho công việc và không thể sử dụng máy tính để bàn docker.

Những gì tôi phải làm là thiết lập các quy tắc tường lửa và portproxy để vượt qua tường lửa wsl và windows. Bạn sẽ cần ip của bộ điều hợp ethernet máy chủ, vì vậy hãy chạy ipconfig trong windows để lấy. Bạn cũng sẽ cần cổng lắng nghe cho dịch vụ trên windows và ip WSL (ifconfig trong wsl, tìm kiếm giá trị inet ivp4 của eth0).

Các lệnh cho các quy tắc tường lửa từ powershell trên Máy chủ:

Mới-NetFireWallRule -DisplayName 'Mở khóa tường lửa WSL' -Direction Outbound -LocalPort your_port_here -Action Allow -Protocol TCP

New-NetFireWallRule -DisplayName 'Mở khóa tường lửa WSL' -Direction Inbound -LocalPort your_port_here -Action Allow -Protocol TCP

Khi bỏ qua tường lửa của windows, sau đó bạn có thể "chuyển tiếp" các cổng sang wsl từ dấu nhắc của windows:

portproxy giao diện netsh thêm v4tov4 listenport=your_port_here listenaddress=host_ip_here connectport=your_port_here connectaddress=wsl_ip_here

Khi bạn đã chạy tất cả các lệnh, bạn sẽ có thể truy cập dịch vụ máy chủ thông qua <host_ip>:<host_port> từ vùng chứa.

Điểm:0
lá cờ cn

Sau rất nhiều lần thử, giải pháp đến từ một bình luận khó hiểu trong các vấn đề về github: https://github.com/Microsoft/WSL/issues/1032#issuecomment-891618766

Về cơ bản:

nếu bạn cũng sử dụng Docker Desktop, bạn có thể truy cập máy chủ Windows của mình bằng host.docker.internal

Đă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.