Điểm:0

Không thể gửi hoặc nhận thư khi được kết nối với máy chủ OpenVPN (máy chủ thư cũng đang chạy trên đó)

lá cờ in

Hiện tại tôi đang gặp một chút khó khăn ở đây và sẽ đánh giá cao mọi nỗ lực hướng tới đúng hướng để giải quyết vấn đề này.

Hai mục tiêu của tôi là để máy chủ OpenVPN chạy trên máy ảo từ xa (Digital Ocean Droplet) và cũng chạy máy chủ postfix của tôi trên máy ảo đó. Kết nối OpenVPN đang định tuyến các truy vấn DNS của tôi tới một Pihole cung cấp cho tôi khả năng chặn quảng cáo phù hợp khi tôi không ở nhà (nơi có một lỗ hổng trên một rpi thực tế đang chạy).

Thiết lập này hoạt động gần như hoàn hảo nhưng có một ngoại lệ. Sau khi kết nối với OpenVPN, tôi không thể nhận hoặc gửi email nữa. Không có gì bật lên trong nhật ký thư của tôi (postfix và dovecot đang chạy và ghi nhật ký) cả.Cả postfix và dovecot đều không ghi lại bất kỳ nỗ lực kết nối nào từ máy photocopy của tôi (sau đó được kết nối với VPN). Khi tôi ngắt kết nối khỏi VPN, việc gửi và nhận thư sẽ hoạt động trở lại.

Tôi có ufw đang chạy và ghi nhật ký nhưng cũng không có gì bật lên trong nhật ký của nó.

Tôi cho rằng nó có liên quan đến hậu tố chạy trên máy chủ cục bộ và sau khi được kết nối với giao diện VPN, có một cây cầu mà tôi phải xây dựng bằng cách nào đó. Nhưng tôi phải thành thật với các bạn, tôi không biết bắt đầu từ đâu với vấn đề này, vì tôi không thể tìm thấy bất cứ điều gì trực tuyến thảo luận chính xác về vấn đề này.

Bạn sẽ nói gì tôi nên bắt đầu tìm kiếm ở đâu? Tường lửa, cấu hình VPN, cấu hình máy chủ thư? Tôi hơi bị lạc lõng.

$ địa chỉ ip
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 trạng thái qdisc noqueue nhóm UNKNOWN mặc định qlen 1000
    liên kết/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    máy chủ phạm vi inet 127.0.0.1/8 lo
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
    inet6 ::1/128 máy chủ phạm vi
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc trạng thái fq_codel UP nhóm mặc định qlen 1000
    liên kết/ether 8a:0c:da:93:21:88 brd ff:ff:ff:ff:ff:ff
    inet XXXXXXXXXXX/20 brd XXXXXXXXXXXX phạm vi toàn cầu eth0
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
    inet 10.19.0.5/16 brd 10.19.255.255 phạm vi toàn cầu eth0
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
    inet6 XXXXXXXXXXXXXXXXXXXXX/64 phạm vi toàn cầu
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
    liên kết phạm vi inet6 XXXXXXXXXXXXXXXXXXXXX/64
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi

[…]

21: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc trạng thái fq_codel UNKNOWN nhóm mặc định qlen 100
    liên kết/không có
    inet 10.8.0.1 ngang hàng 10.8.0.2/32 phạm vi toàn cầu tun0
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
    inet6 XXXXXXXXXXXXXXXXXXXXX/64 liên kết phạm vi ổn định-riêng tư
       hợp lệ_lft mãi mãi ưa thích_lft mãi mãi


$ mèo /etc/openvpn/server.conf
cổng 1194
proto udp
nhà phát triển điều chỉnh
ca ca.crt
máy chủ chứng chỉ.crt
máy chủ khóa.key
dh dh.pem
máy chủ 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
đẩy "tuyến đường 192.168.10.0 255.255.255.0"
đẩy "tuyến đường 192.168.20.0 255.255.255.0"
đẩy "chuyển hướng cổng def1 bỏ qua-dhcp"
đẩy "DNS tùy chọn dhcp 10.8.0.1"
lưu giữ 10 120
tls-auth ta.key 0
mật mã AES-256-CBC
xác thực SHA256
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 /var/log/openvpn/openvpn-status.log
đăng nhập /var/log/openvpn/openvpn.log
động từ 3
rõ ràng-thoát-thông báo 1

OpenVPN ghi nhật ký kết nối máy tính của tôi

Thứ bảy ngày 25 tháng 12 09:10:51 2021 macbook/XXXXXXXXX:59001 MULTI: IP ảo chính cho macbook/XXXXXXXXX:59001: 10.8.0.10
Sat 25 Dec 09:10:51 2021 macbook/XXXXXXXXX:59001 SENT CONTROL [macbook]: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 192.168.20.0 255.255.255.0,redirect-gateway def1 bypass-dhcp-option,dhcption DNS 10.8.0.1,tuyến đường 10.8.0.1,cấu trúc liên kết net30,ping 10,ping-khởi động lại 120,ifconfig 10.8.0.10 10.8.0.9,peer-id 0,mã hóa AES-256-GCM' (trạng thái=1)
lá cờ in
Tôi sẽ bắt đầu với việc đảm bảo rằng các gói được nhận và gửi lại tới đúng địa chỉ IP. `tcpdump -nni bất kỳ cổng 25` nào có thể hữu ích.
lá cờ in
Bản thân thiết lập máy chủ thư hoạt động tốt. Sử dụng tcpdump, nó ghi lại các thư đến. Vấn đề là, khi máy khách của tôi được kết nối với máy chủ openvpn (trên cùng một máy chủ), nó không thể kết nối với máy chủ thư. Khách hàng của tôi đang cố gắng kết nối nhưng cuối cùng sẽ hết thời gian chờ. Khi tôi ngắt kết nối máy khách của mình khỏi máy chủ openvpn, nó sẽ nhận và gửi lại thư. Về phía máy chủ, không có gì bật lên trong mail.log
lá cờ in
Ý tôi là kiểm tra tcpdump trong khi bạn đang cố kết nối...
lá cờ in
kiểm tra `ip route` trên cả máy chủ và máy khách, thử và hiểu đường dẫn mà các gói sẽ đi, đồng thời xem xét đường dẫn bên ngoài của dịch vụ VPN.
lá cờ in
Nó có thể sẽ là một vấn đề định tuyến. Nhưng tôi nghĩ rằng trước tiên tôi thực sự cần phải tự học về định tuyến mạng, bởi vì hiện tại tôi không biết nên bắt đầu từ đâu. Một điều đã đưa ra và có thể được liên quan.Khi ứng dụng khách của tôi cố gắng kết nối với máy chủ thư của tôi bằng telnet và trong khi được kết nối với Máy chủ OpenVPN, nó sẽ không giải quyết chính xác DNS của máy chủ thư. Nó chạy qua 127.0.1.1 và bị kẹt khi thực hiện việc này. Sau khi ngắt kết nối khỏi Máy chủ OpenVPN, nó sẽ giải quyết chính xác mục nhập DNS và kết nối với máy chủ thư. Đây có phải là một cái gì đó chúng ta có thể làm việc với?
lá cờ in
`# đã kết nối với máy chủ openvpn thư telnet.MAILSERVER.de 25 Đang thử 127.0.1.1... # không được kết nối với máy chủ openvpn`
lá cờ in
`telnet mail.MAILSERVER.de 25 Đang thử XX.XXX.XXX.XXX... Đã kết nối với mail.MAILSERVER.de. Ký tự thoát là '^]'. 220 mail.MAILSERVER.de ESMTP Postfix`
lá cờ in
Vì vậy, khi được kết nối với máy chủ OpenVPN, máy khách sẽ cố gắng giải quyết mục nhập DNS của máy chủ thư của tôi và vì một lý do nào đó mà tôi không hiểu hết, đã cố gắng kết nối với 127.0.1.1. Nếu tôi cố gắng kết nối trực tiếp với IP của máy chủ thư của mình, telnet có thể kết nối bình thường. $ điện thoại XX.XXX.XXX.XXX 25 Đang thử XX.XXX.XXX.XXX... Đã kết nối với NAMEOFLOCALHOST. Ký tự thoát là '^]'. 220 mail.MAILSERVER.de ESMTP Postfix
lá cờ in
Vậy làm cách nào để OpenVPN không giải quyết mục nhập DNS thành IP cục bộ của tôi mà là IP công cộng? Tôi cho rằng điều này sẽ giải quyết điều này.
Điểm:0
lá cờ aq
MTG

Cấu hình VPN có thể rất phức tạp vì nó thay đổi tuyến đường mặc định bình thường của hệ thống thành tuyến đường của máy chủ VPN. Ngược lại, máy chủ có thể thực hiện một số loại định tuyến nguồn cho lưu lượng truy cập đến từ máy khách vpn, cũng như thay đổi địa chỉ IP gửi đi của bạn.

Tóm tắt:

  1. Máy chủ thư có thể nhạy cảm với sự thay đổi địa chỉ đó.

  2. Dịch vụ VPN có thể hướng lưu lượng truy cập của bạn đến giao diện vật lý hoặc công khai của nó, ngăn chặn hiệu quả bạn khỏi các dịch vụ nội bộ của VM, bao gồm cả bộ postfix.

  3. Tính năng chặn quảng cáo cũng có thể gây ra sự cố với dịch vụ e-mail.

Tốt hơn hết bạn nên tìm kiếm các tùy chọn cấu hình có liên quan của Pihole hoặc thử các dịch vụ VPN khác cho tốt, ví dụ:. dịch vụ Linux VPN gốc cho người mới bắt đầu.

lá cờ in
VPN có thể được định cấu hình để trở thành tuyến mặc định, nhưng đó là cấu hình chứ không phải mặc định.

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