Điểm:0

Định tuyến OpenVPN đến chính máy chủ qua đường hầm

lá cờ cn

Tôi muốn sử dụng kết nối OpenVPN để truy cập tài nguyên cục bộ của mình. Tôi có iptables thiết lập để cho phép kết nối từ 192.168.1.0/24 mạng con. Khi tôi kết nối từ điện thoại hoặc máy Windows, mọi thứ đều hoạt động hoàn hảo. Nhưng khi tôi cố gắng kết nối từ Ubuntu thì không được.

Sau khi kiểm tra tcpdump và đọc rất nhiều nhật ký, tôi thấy rằng các gói từ Ubuntu có SRC=ip trắng thực trong khi cho điện thoại hoặc Windows SRC=ip đường hầm cục bộ và nó hoạt động như mong đợi.

Sau đó, tôi đã kiểm tra các tuyến đường của mình khi được kết nối với VPN và tìm thấy thông tin sau (giả sử 77.77.77.77 - Máy chủ OpenVPN, 192.168.8.1 - bộ định tuyến của tôi):

Cổng đích Genmask Flag Metric Ref Sử dụng Iface
0.0.0.0 192.168.255.5 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 192.168.8.1 0.0.0.0 UG 600 0 0 wlp2s0
77.77.77.77 192.168.8.1 255.255.255.255 UGH 600 0 0 wlp2s0
192.168.8.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0
192.168.8.1 0.0.0.0 255.255.255.255 UH 600 0 0 wlp2s0
192.168.255.1 192.168.255.5 255.255.255.255 UGH 50 0 0 tun0
192.168.255.5 0.0.0.0 255.255.255.255 UH 50 0 0 tun0

Tôi tin rằng gốc rễ của vấn đề của tôi là:

77.77.77.77 192.168.8.1 255.255.255.255 UGH 600 0 0 wlp2s0

như nó nói sử dụng bộ định tuyến của tôi làm cổng để truy cập vào chính máy chủ VPN. Kết quả là tôi thấy địa chỉ IP thực của mình thay vì địa chỉ IP đường hầm.

Nhưng tôi không hiểu làm thế nào để khắc phục điều này. Tôi đã thử sửa đổi tuyến đường theo cách thủ công để định tuyến lưu lượng truy cập đến máy chủ qua đường hầm nhưng không hiệu quả:

77.77.77.77 192.168.255.5 255.255.255.255 UGH 600 0 0 tun0

Vì vậy, nếu tất cả điều tra của tôi được hiểu chính xác, để giải quyết vấn đề, tôi cần định tuyến lưu lượng truy cập đến chính máy chủ vpn qua đường hầm thay vì cổng mặc định. tôi cho là cổng chuyển hướng def1 chỉ thị nên chuyển hướng TẤT CẢ CÁC lưu lượng truy cập qua VPN, bao gồm cả chính nó.Nhưng có vẻ như nó không.

Của tôi máy chủ.conf:

máy chủ 192.168.255.0 255.255.255.0
động từ 3
khóa /etc/openvpn/pki/private/vpn.example.com.key
ca /etc/openvpn/pki/ca.crt
chứng chỉ /etc/openvpn/pki/issued/vpn.example.com.crt
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/pki/ta.key
hướng chính 0
lưu giữ 10 60
phím kiên trì
kiên trì điều chỉnh
proto udp
cổng 1194
nhà phát triển tun0
trạng thái /tmp/openvpn-status.log
người dùng không ai
nhóm không có nhóm
tuyến đường 192.168.254.0 255.255.255.0
đẩy "chặn-bên ngoài-dns"
đẩy "DNS tùy chọn dhcp 192.168.1.1"
đẩy "lan DOMAIN tùy chọn dhcp"

Của tôi khách hàng.ovpn:

khách hàng
quý tộc
nhà phát triển điều chỉnh
máy chủ từ xa-cert-tls
từ xa vpn.example.com 1194 udp
...giấy chứng nhận...
hướng chính 1
cổng chuyển hướng def1
Tom Yan avatar
lá cờ in
Bạn dường như đang nói về hai vấn đề riêng biệt không liên quan. Việc truy cập các dịch vụ khác trên máy chủ VPN của bạn hoặc các máy chủ khác trong mạng LAN của máy chủ không liên quan gì đến tuyến địa chỉ từ xa. Vui lòng làm rõ mục tiêu của bạn (không phỏng đoán lung tung) và thiết lập (ví dụ:cho dù máy chủ VPN của bạn đứng sau NAT hay có cấu hình IP công khai trực tiếp trên đó)
ihorc avatar
lá cờ cn
Tôi muốn truy cập dịch vụ được lưu trữ trên máy chủ VPN của mình theo tên miền, ví dụ: https://mysite.example.com, được trỏ đến 77.77.77.77. Máy chủ VPN đứng sau NAT, nhưng tất cả cấu hình chuyển tiếp cổng và tường lửa được thực hiện đúng cách, vì tôi có thể truy cập nó như mong đợi từ các thiết bị khác có cùng cấu hình. Ngoài ra, mọi thứ đều hoạt động tốt mà không bị giới hạn ở 192.168.1.0/24 từ nơi công cộng. Vấn đề duy nhất là máy khách linux hiển thị IP thực của anh ấy thay vì IP đường hầm, do đó, nó không thể vượt qua quy tắc iptables tương ứng (-A INPUT -s 192.168.1.0/24 -j ACCEPT).
Nikita Kipriyanov avatar
lá cờ za
Điều này là không thể. Hoặc, tôi nên nói rằng, bạn phải thiết lập các bản ghi DNS SVCB khá tò mò cho điều đó, điều này nằm ngoài phạm vi của câu hỏi như thể nó đã được xây dựng. Nói chung, bạn *hoặc* phải sử dụng địa chỉ IP "nội bộ" (được đóng gói) để truy cập trang web (vì vậy lưu lượng truy cập sẽ đi qua VPN) hoặc địa chỉ IP "công khai" cũng được sử dụng làm điểm cuối VPN, nhưng lưu lượng truy cập sẽ không đi qua VPN, vì bạn cần một tuyến đường trực tiếp (không qua VPN) đến địa chỉ IP đó để tự thiết lập kênh VPN. **TẠI SAO bạn cần điều đó?**
ihorc avatar
lá cờ cn
Tại sao nó hoạt động trên điện thoại hoặc máy khách Windows? >>> Tại sao bạn cần điều đó? - Để truy cập các trang web của tôi như bình thường theo tên miền. Nhưng làm cho chúng chỉ có thể truy cập được bằng VPN.
Nikita Kipriyanov avatar
lá cờ za
Bạn có chắc nó hoạt động theo cách đó không? Tôi thực sự nghi ngờ điều đó. Ngoài ra, mã hóa của OpenVPN hoàn toàn giống với mã hóa trong HTTPS và tính bảo mật cũng giống như vậy; tại sao lại sử dụng VPN cho điều đó?
ihorc avatar
lá cờ cn
Vâng tôi chắc chắn. >>> Tại sao lại sử dụng VPN cho điều đó? - Rõ ràng là để hạn chế quyền truy cập của công chúng vào các trang web của tôi.
Tom Yan avatar
lá cờ in
Có thể để máy chủ DNS cho máy khách VPN phân giải miền thành IP VPN của máy chủ là cách rõ ràng nhất, mặc dù về mặt kỹ thuật, bạn có thể sử dụng định tuyến chính sách để chỉ định tuyến một số lưu lượng nhất định (ví dụ: dựa trên dport) tới `77.77.77.77` qua Cổng Internet của khách hàng.Tuy nhiên, liệu điều đó cuối cùng có kết thúc tốt đẹp hay không còn phụ thuộc vào những thứ khác, vì rõ ràng đó là một kiểu kẹp tóc khá khó chịu mà chúng ta đang nói đến ở đây.
Tom Yan avatar
lá cờ in
Nhân tiện, có lẽ sẽ bớt khó chịu hơn nếu bạn cũng chuyển hướng (như trong, tự chuyển hướng sang chính nó) lưu lượng truy cập tại máy chủ VPN, để chúng không đến được bộ định tuyến của nó và sau đó bị kẹp tóc trở lại, nếu bạn quyết tâm đi xuống theo cách đó.
ihorc avatar
lá cờ cn
Nếu ý bạn là quy tắc MASQUERADE thì nó đã có rồi. Tôi khá chắc chắn rằng đó là điều gì đó về sự khác biệt của NAT Loopback trên các hệ điều hành máy khách khác nhau. Đó không phải là vấn đề liên quan đến máy chủ, nếu không thì nó sẽ không hoạt động trên bất kỳ thiết bị nào. Vì vậy, về cơ bản, mục tiêu của tôi rất đơn giản - làm cho một trang web có thể truy cập được chỉ bằng VPN, nhưng thoạt nhìn có vẻ phức tạp hơn.
Tom Yan avatar
lá cờ in
Không, ý tôi là quy tắc REDIRECT cho địa chỉ đích 77.77.77.77. Nhưng đó không phải là một gợi ý cho vấn đề hiện tại của bạn, chỉ là một mẹo bổ sung nếu bạn muốn gắn bó với mong muốn/cách tiếp cận kỳ quặc này. Và vấn đề hiện tại của bạn không phải là về NAT Loopback, mà là cách thiết lập tuyến đường cho `77.77.77.77` trên nền tảng máy khách khác. (Dự kiến ​​*không* hoạt động trên Linux trừ khi bạn tùy chỉnh thiết lập tuyến đường như tôi đã đề cập; không chắc chắn về Windows nhưng trên Android, mọi ứng dụng đều có bảng lộ trình riêng để ứng dụng có thể hoạt động tốt.)
Tom Yan avatar
lá cờ in
TL; DR, nghiên cứu về định tuyến chính sách a.k.a. quy tắc ip. Tôi không nghĩ rằng có bất kỳ tùy chọn cấu hình ovpn nào có thể giúp bạn đạt được những gì bạn muốn, ngoài thực tế là bạn sẽ cần phải loại bỏ/lọc các tuyến đường đẩy/thiết lập mặc định như `cổng chuyển hướng`)

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