Điểm:0

Nginx sees OpenVPN linux client with its public IP address while android client is seen with private VPN IP address

lá cờ tr

I've set up the following virtual server in my NGINX conf:

server {
   listen 80;
   listen [::]:80;   
   server_name ip.myserver.com; 
   location / {
     default_type text/plain;
     return 200 "$remote_addr\n";
   }
}

The idea is that I have some other virtual servers that I want to access only using the OpenVPN connection which is on the same machine. Using this test site, it should display the private IP address (or public if not connected to the VPN).

My Android phone works perfectly:

While connecting to the site without VPN connection it displays the following: 192.0.2.222. (It has another address in reality, of course.)

When connecting to the site using the VPN connection, the following is displayed 10.8.0.3, this is the correct result as it is showing that the device is using the VPN connection and since the VPN service and Nginx server are on the same machine, Nginx sees the private IP of the VPN.

When doing this on my Linux machine, it displays the Linux machine's public IP address when connecting to the server without a VPN connection, and when connecting with a VPN connection it displays the server's public IP address, which is not what I expected.

I suspect there's something wrong with the way OpenVPN is configured on my Linux laptop, as the Android phone is working fine.

OpenVPN Server Config:

port 1194
proto udp6
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 94.140.14.14"
push "dhcp-option DNS 94.140.15.15"
push "redirect-gateway def1 bypass-dhcp"
server-ipv6 fd42:42:42:42::/112
tun-ipv6
push tun-ipv6
push "route-ipv6 2000::/3"
push "redirect-gateway ipv6"
dh none
ecdh-curve prime256v1
tls-crypt /etc/openvpn/tls-crypt.key
crl-verify /etc/openvpn/crl.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server_key.crt
key /etc/openvpn/server_key.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 4

OpenVPN Client File (Without keys):

client
proto udp
explicit-exit-notify
remote 192.0.2.222 1194 # Changed this  for display.
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_key name # Changed this because not sure if private info
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3
Nikita Kipriyanov avatar
lá cờ za
Trên thực tế, chúng tôi không cần cấu hình Nginx của bạn, mà cần cấu hình OpenVPN. Vui lòng [đính kèm](https://serverfault.com/posts/1102361/edit) chúng vào câu hỏi. Ngoài ra, hãy lưu ý rằng nếu bạn che dấu địa chỉ IP công cộng, thì đừng sử dụng bất kỳ địa chỉ ngẫu nhiên nào mà hãy chọn một địa chỉ từ [RFC5737](https://www.rfc-editor.org/rfc/rfc5737.html)
lá cờ tr
Tôi cho rằng các cấu hình OpenVPN của tôi sẽ ổn và lỗi sẽ xảy ra với máy tính xách tay Linux của tôi nhưng tôi sẽ đăng chúng cho rõ ràng. Vui lòng xem mô tả sửa đổi ...
Nikita Kipriyanov avatar
lá cờ za
Tôi nghi ngờ các ứng dụng khách khác nhau xử lý các tùy chọn `redirect-gate` kép *push*-ed khác nhau. Chẳng hạn, tùy chọn thứ hai có thể ghi đè lên tùy chọn đầu tiên hoặc không. Bạn sẽ không thử kết hợp chúng thành một tùy chọn duy nhất chứ? Ngoài ra, nếu có thể, hãy đính kèm `ip route` từ máy khách Linux được kết nối ngay sau khi VPN được kết nối.
lá cờ tr
Tôi cần sửa đổi nó như thế nào để bao gồm mọi thứ trong một câu lệnh đẩy? Tôi xin lỗi vì sự thiếu hiểu biết của tôi về vấn đề này.
Nikita Kipriyanov avatar
lá cờ za
Ý tôi là, thay vì hai `push "redirect-gateway..."`, hãy chỉ sử dụng một `push "redirect-gateway def1 bypass-dhcp ipv6"`.
lá cờ tr
Đây là những gì IP ROUTE hiển thị: `0.0.0.0/1 qua 10.8.0.1 dev tun0 mặc định qua 198.51.100.1 dev wlo1 proto dhcp src 10.51.205.131 số liệu 600 10.8.0.0/24 dev tun0 liên kết phạm vi kernel proto src 10.8.0.2 10.51.192.0/20 dev wlo1 liên kết phạm vi kernel proto src 10.51.205.131 số liệu 600 128.0.0.0/1 qua 10.8.0.1 dành cho nhà phát triển0 198.51.100.0/24 dev virbr0 liên kết phạm vi hạt nhân proto src 198.51.100.122 liên kết xuống 198.51.100.32 qua 198.51.100.1dev wlo1 ` Tôi đã đổi địa chỉ IP để bảo mật :)

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