MULTI: địa chỉ nguồn xấu từ khách hàng - bất kỳ giải pháp một lần nào?


10

Thiết lập: Tôi có một thiết lập máy khách / máy chủ openvpn (tập tin cấu hình ở dưới cùng) và tôi nhận được MULTI: bad source address from client [192.168.x.x], packet droppedthông báo tai tiếng ở máy chủ. Máy chủ có một địa chỉ IP công cộng, trong khi máy khách đứng sau NAT.

Thiếu sót của các giải pháp được đề xuất trước đây: Định client-config-dirnghĩa trong cấu hình máy chủ hiện đang trống. Các bài đăng trước đây (tại đây và trong các diễn đàn hỗ trợ openvpn) đề nghị thêm một tệp có tên theo DEFAULTquy tắc phù hợp client-config-dirhoặc thêm tệp cho mỗi người dùng với các quy tắc đó để giải quyết vấn đề.

Tuy nhiên, đây dường như không phải là một giải pháp lâu dài, bởi vì các quy tắc này là dành riêng cho địa điểm của khách hàng. Vì vậy, tôi có thể thêm một quy tắc để cho phép khách hàng 192.168.x.0kết nối. Nhưng nếu họ kết nối từ một mạng khác thay vì sử dụng 192.168.y.0cho NAT, một quy tắc mới sẽ được yêu cầu.

Câu hỏi:

  • Các quy tắc cần thiết có thể được viết theo cách chung / một lần không?
  • Ai đó có thể giải thích tại sao vấn đề này xảy ra ở nơi đầu tiên?

Cấu hình máy chủ:

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

Cấu hình máy khách:

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

Có phải tất cả khách hàng của bạn trên các mạng 192.168.xy không?
IceMage

Nó không rõ ràng đối với tôi ... Bạn có nghĩa là bạn muốn định tuyến theo một cách khác một khách hàng đang bật 192.168.x.0và một khách hàng trên 192.168.y.0mạng? Tất cả chúng đều nằm trong cùng một 192.168.x.x/16mạng mà bạn đã xác định ... (?)
krisFR

Câu trả lời:


12

Bạn hỏi: " Ai đó có thể giải thích tại sao vấn đề này xảy ra ngay từ đầu không? "

Dựa trên những gì được báo cáo trong Câu hỏi thường gặp về OpenVPN chính thức, tôi cá rằng nó gây ra bởi một vấn đề định tuyến trong công cụ OpenVPN.

Để làm rõ hơn kịch bản, hãy để tôi tham khảo sơ đồ sau:

Ở đây bạn có thể thấy:

  • một "máy chủ" OpenVPN được kết nối với mạng nội bộ HEADQUARTER (10.0.1.0/24)
  • một "máy khách" OpenVPN đang chạy tại một Trang web từ xa và được kết nối với mạng 192.168.1.0/24 từ xa

Cũng thế

  • chúng tôi giả định rằng đường hầm OpenVPN được thiết lập và:
    • OpenVPN "máy chủ" có thể truy cập thông qua riêng của mình tun giao diện, với địa chỉ 10.10.0.1. Ngoài ra, địa chỉ P2P, được sử dụng bởi giao diện điều chỉnh là 10.10.0.2 ( điều này rất quan trọng cho cuộc thảo luận sau này, vì vậy hãy nhấn mạnh nó )
    • OpenVPN "khách hàng" có một tun giao diện với IP 10.10.0.2

Bây giờ, hãy giả sử rằng:

  • "Máy khách" OpenVPN đã xác định lại cổng mặc định của nó, do đó, để chuyển hướng trong đường hầm tất cả lưu lượng IP đi;
  • "Máy khách" OpenVPN đã kích hoạt IP_FORWARDING và, do đó, có thể định tuyến các gói đến từ mạng LAN nội bộ của nó (192.168.1.0/24) ( tôi nhấn mạnh điểm này, vì nó rất quan trọng cho cuộc thảo luận của chúng tôi ).

Với kịch bản như vậy, hãy kiểm tra chi tiết những gì xảy ra khi R_PC1 (192.168.1.2) gửi một gói, như yêu cầu echo, đến L_PC1 (10.0.1.2):

  1. sau khi rời R_PC1 NIC, gói tiếp cận máy khách OpenVPN;
  2. Máy khách OpenVPN (được cấu hình để hoạt động như một bộ định tuyến chung), định tuyến nó theo bảng định tuyến của nó. Vì cổng mặc định là đường hầm, nó sẽ gửi gói đến đường hầm;
  3. Gói tiếp cận giao diện điều chỉnh của máy chủ OpenVPN. OpenVPN sẽ "nhìn thấy" nó và, vì nó (máy chủ OpenVPN) biết rằng 10.0.1.2 là một địa chỉ thuộc mạng con LAN của nó, nó "chuyển tiếp" gói tin, từ TUN sang LAN;
  4. Gói đạt L_PC1.

Vì vậy, mọi thứ đều ổn ...

Bây giờ, hãy kiểm tra xem điều gì xảy ra với phản hồi echo mà L_PC1 trả lời cho R_PC1.

  1. echo-reply rời L_PC1 NIC và tiếp cận giao diện LAN của máy chủ OpenVPN (10.0.1.1);

Bây giờ, nếu chúng ta muốn OpenVPN Server có thể truy cập trang web từ xa, chúng ta cần xác định định tuyến bằng "tuyến tĩnh". Cái gì đó như:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

Xin lưu ý địa chỉ P2P được sử dụng làm cổng .

Các tuyến tĩnh như vậy sẽ hoạt động ở cấp độ hệ điều hành. Nói cách khác, hệ điều hành cần định tuyến đúng gói. Nó có nghĩa như sau: "Xin vui lòng, tất cả lưu lượng truy cập đến mạng con 192.168.1.0/24 cần được chuyển tiếp đến công cụ OpenVPN, mà HĐH có thể nói chuyện qua địa chỉ P2P". Nhờ tuyến đường tĩnh như vậy, giờ ...

  1. gói rời khỏi bối cảnh định tuyến hệ điều hành và đến OpenVPN. Phiên bản OpenVPN đang chạy trên Máy chủ OpenVPN. Vì vậy, tại thời điểm này, HĐH không còn gì để làm và tất cả các định tuyến (trong VPN) được để lại cho phần mềm máy chủ OpenVPN.

Vì vậy, bây giờ, vấn đề là: làm thế nào, phần mềm máy chủ openvpn, sẽ có thể quyết định tuyến đường của gói, với SRC_IP 10.0.1.2 và DST_IP 192.168.1.2 ?

Xin lưu ý rằng, dựa trên cấu hình của máy chủ OpenVPN, nó không biết về mạng 192.168.1.0/24, cũng như máy chủ 192.168.1.2. Nó không phải là một khách hàng được kết nối. Đó không phải là một khách hàng địa phương. Và vì thế? OpenVPN, cũng biết rằng đó không phải là "Bộ định tuyến hệ điều hành", vì vậy nó không thực sự muốn (và có thể ....) gửi gói trở lại cổng cục bộ. Vì vậy, lựa chọn duy nhất, ở đây, là đưa ra một lỗi. Chính xác là lỗi bạn gặp phải

Nói với ngôn ngữ của Câu hỏi thường gặp: " ... nó không biết cách định tuyến gói đến máy này, vì vậy nó làm rơi gói ... ".

Làm thế nào chúng ta có thể giải quyết vấn đề?

Như bạn có thể thấy từ tài liệu chính thức , tùy chọn iroute phục vụ chính xác đến phạm vi của chúng tôi:

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

Vì vậy, bạn cần một:

--iroute 192.168.1.0 255.255.255.0

được áp dụng (cho máy chủ) khi máy khách OpenVPN của bạn kết nối, ví dụ như thông qua tệp cấu hình đặc biệt được xác định trên máy chủ (client-config-dir, v.v.).

Nếu bạn thắc mắc tại sao vấn đề này không xảy ra ở bước 2) ở trên, thì tôi hiểu rằng OpenVPN Client biết cách định tuyến nó, vì nó biết rằng đường hầm VPN là một cổng mặc định.

Điều tương tự không thể được thực hiện tại OpenVPN Server, vì có cổng mặc định không bị ghi đè. Ngoài ra, hãy xem xét rằng bạn có thể có một máy chủ OpenVPN có nhiều máy khách OpenVPN: mỗi máy khách biết cách truy cập máy chủ nhưng ... làm thế nào, máy chủ có thể quyết định máy khách nào đóng vai trò là cổng cho mạng con không xác định?


Đối với câu hỏi đầu tiên của bạn (Các quy tắc bắt buộc có thể được viết theo cách chung / một lần không? ), Tôi xin lỗi nhưng tôi không gặp phải vấn đề của bạn. Bạn có thể viết lại cung cấp thêm chi tiết?



Trả lời câu hỏi cuối cùng của bạn: Tôi không muốn chỉnh sửa cấu hình iroute mỗi khi ứng dụng khách OpenVPN kết nối từ một Wi-Fi công cộng khác chỉ vì nó có địa chỉ mạng cục bộ khác nhau.
jollyroger

1
@jollyroger: trong kịch bản "chiến binh đường bộ" (một PC duy nhất đóng vai trò là khách hàng vpn đối với máy chủ openpn) bạn không cần bất kỳ chỉ thị "không định tuyến" nào! Vì vậy, nếu bạn kết nối qua wifi công cộng, tôi chắc chắn bạn không cần nó. Bạn sẽ chỉ cần nó trong các cấu hình LAN-to-LAN chính thức, trong đó phía sau máy khách OpenVPN, bạn có toàn bộ mạng được máy chủ OpenVPN truy cập. Tôi chắc chắn rằng đây không phải là trường hợp khi bạn kết nối ... "từ một Wi-Fi công cộng khác". Nếu giả định của tôi sai, vui lòng cung cấp chi tiết về cấu hình mạng chính của bạn (đặc biệt là khi kết nối qua wifi công cộng)
Damiano Verzulli

Điều này chủ yếu liên quan đến việc sử dụng SIP qua OpenVPN. Giả sử bạn có 192.168.0.111/24 trên wlan0 và 10.10.10.5/30 trên tun0 của bạn được kết nối với OpenVPN. Giả sử máy chủ OpenVPN có thêm mạng 10.11.10.2/24 với Asterisk vào ngày 10.11.10.1 và tất cả các tuyến cần thiết được đẩy đến máy khách (ping thành công theo cả hai hướng). Vấn đề là SIP có thể quyết định định tuyến các gói có IP nguồn của wlan0 của bạn đến giao diện tun0 thay vì sử dụng IP nguồn tun0 và đây là khi bạn gặp sự cố - dấu hoa thị sẽ nghĩ bạn là NAT-ed mặc dù bạn không phải vậy.
jollyroger

@jollyroger: nếu tôi đúng, hoàn toàn có thể có các máy khách SIP phía sau các hộp NAT, do đó, nó sẽ có khả năng, trong ứng dụng khách OpenVPN của bạn, đối với lưu lượng VPN ra bên ngoài của NAT (rời khỏi giao diện tun0). Có một số lý do cụ thể tại sao điều này không phải là một lựa chọn, cho bạn?
Damiano Verzulli

Nó hoạt động. nhưng không đáng tin cậy (đọc bình luận trước đây của tôi) do bản chất của SIP và các máy khách bị lỗi và sau này không thay đổi trong nhiều năm. Chắc chắn, tôi có thể kích hoạt tính năng ủy quyền tất cả lưu lượng truy cập thông qua máy chủ Asterisk của mình, nhưng điều này giới hạn các máy khách chỉ sử dụng codec được máy chủ hỗ trợ mặc dù có khả năng định tuyến các gói RTP trực tiếp chỉ với bộ giải mã từ máy khách sang máy khách.
jollyroger

1

Tôi đã có một vấn đề có vẻ tương tự, nhưng tôi không chắc nó có giống như vấn đề của bạn không. Tôi đã cố gắng ping từ máy khách openvpn đến máy tính trong mạng cục bộ của máy chủ openvpn (được định tuyến trong cấu hình của máy chủ), không nhận được phản hồi và tôi có thể thấy thông báo "địa chỉ nguồn xấu" trong nhật ký openvpn của máy chủ.

Để giải quyết nó, tôi đã phải làm 2 việc:

  1. Cho phép chuyển tiếp ip trên máy chủ.
  2. Thêm một tuyến đường cho mạng con vpn trên cổng của máy chủ, bởi vì cổng cho mạng cục bộ của máy chủ trong trường hợp của tôi không phải là máy chủ, mà là một bộ định tuyến. Máy tính ping đã cố gắng trả lời qua cổng, không biết phải làm gì cho mạng con vpn. Vì vậy, tôi đã thêm một tuyến tĩnh trong bộ định tuyến bằng cách sử dụng mạng con vpn cho đích và ip của máy chủ openvpn làm cổng cho nó.

Điều đó đã sửa nó cho tôi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.