Puncte:0

Nu pot trimite sau primi e-mailuri atunci când sunt conectate la serverul OpenVPN (pe care rulează și serverul de e-mail)

drapel in

Sunt puțin blocat aici în acest moment și voi aprecia fiecare împingere către direcția corectă pentru a rezolva această problemă.

Cele două obiective ale mele sunt să obțin un server OpenVPN care rulează pe un VM la distanță (Digital Ocean Droplet) și, de asemenea, să rulez serverul meu postfix pe acel VM. Conexiunea OpenVPN îmi direcționează interogările DNS către un Pihole, care îmi oferă o blocare adecvată a anunțurilor atunci când nu sunt acasă (unde există un pihole pe un rpi real care rulează).

Această configurație funcționează aproape perfect, dar cu o singură excepție. Odată conectat la OpenVPN, nu mai pot primi sau trimite e-mailuri. Nu apare nimic în jurnalul meu de e-mail (postfix și porumbel rulează și înregistrează) deloc.Nici postfix, nici dovecot nu înregistrează nicio încercare de conectare de la copmuterul meu (care apoi este conectat la VPN). Odată ce mă deconectez de la VPN, trimiterea și primirea e-mailurilor funcționează din nou.

Am ufw care rulează și înregistrează, dar nici nu apare nimic în jurnalele sale.

Presupun că are ceva de-a face cu postfix care rulează pe localhost și odată conectat la interfața VPN există o punte pe care trebuie să-l construiesc cumva. Dar trebuie să fiu sincer cu voi, băieți, nu am idee de unde să încep cu asta, deoarece nu găsesc nimic online unde se discută exact această problemă.

Ce ai spune de unde ar trebui să încep să caut? Firewall, configurare VPN, configurare server de mail? Sunt un pic pierdut.

$ adresa ip
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 ::1/128 scope host
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 8a:0c:da:93:21:88 brd ff:ff:ff:ff:ff:ff
    inet XXXXXXXXXXX/20 brd XXXXXXXXXXXX domeniu global eth0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet 10.19.0.5/16 brd 10.19.255.255 scope global eth0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 XXXXXXXXXXXXXXXXXXXXXX/64 domeniu global
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    link pentru domeniul inet6 XXXXXXXXXXXXXXXXXXXXXX/64
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

[...]

21: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state NECUNOSCUT grup implicit qlen 100
    link/niciuna
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 XXXXXXXXXXXXXXXXXXXXXX/64 scope link stabil-confidențialitate
       valid_lft pentru totdeauna preferred_lft pentru totdeauna


$ cat /etc/openvpn/server.conf
portul 1194
proto udp
dev tun
ca ca.crt
cert server.crt
cheie server.cheie
dh dh.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
apăsați „route 192.168.10.0 255.255.255.0”
apăsați „route 192.168.20.0 255.255.255.0”
push "redirect-gateway def1 bypass-dhcp"
apăsați „dhcp-option DNS 10.8.0.1”
menține în viață 10 120
tls-auth ta.key 0
cifrul AES-256-CBC
auth SHA256
utilizator nimeni
grup fără grup
cheie-persiste
persist-tun
stare /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verbul 3
explicit-exit-notify 1

OpenVPN înregistrează conexiunea computerului meu

Sâmbătă, 25 decembrie 09:10:51 2021 macbook/XXXXXXXXX:59001 MULTI: IP virtual principal pentru macbook/XXXXXXXXX:59001: 10.8.0.10
Sâmbătă, 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.20.0. DNS 10.8.0.1, ruta 10.8.0.1, topologie net30, ping 10, ping-repornire 120, ifconfig 10.8.0.10 10.8.0.9, peer-id 0, cifră AES-256-GCM' (starea=1)
drapel in
Aș începe prin a mă asigura că pachetele sunt primite de la și trimise înapoi la IP-urile corecte. `tcpdump -nni orice port 25` ar putea ajuta.
drapel in
Configurarea serverului de e-mail în sine funcționează bine. Folosind tcpdump, înregistrează e-mailurile primite. Problema este că, odată ce clientul meu este conectat la serverul openvpn (care este pe același server), nu se poate conecta la serverul de e-mail. Clientul meu încearcă să se conecteze, dar în cele din urmă va expira. Când îmi deconectez clientul de la serverul openvpn, acesta primește și trimite e-mailuri din nou. Pe partea de server nu apare nimic în mail.log
drapel in
Mă refeream la verificarea tcpdump în timp ce încercați să vă conectați...
drapel in
verificați `ruta IP` atât pe server, cât și pe client, încercați să înțelegeți ce cale o vor lua pachetele, luând în considerare și calea externă a serviciului VPN.
drapel in
Probabil va fi o problemă de rutare. Dar cred că trebuie să mă educ mai întâi cu privire la rutarea rețelei, pentru că acum nu am o idee bună de unde să încep. A apărut un lucru și ar putea fi legat.Când clientul meu încearcă să se conecteze la serverul meu de e-mail folosind telnet și în timp ce este conectat la OpenVPN-Server, nu rezolvă corect DNS-ul serverului de e-mail. Se execută prin 127.0.1.1 și se blochează în acest sens. Odată deconectat de la serverul OpenVPN, rezolvă corect intrarea DNS și se conectează la serverul de e-mail. Este ceva cu care putem lucra?
drapel in
`# conectat la serverul openvpn telnet mail.MAILSERVER.de 25 Încercați 127.0.1.1... # nu este conectat la serverul openvpn`
drapel in
`telnet mail.MAILSERVER.de 25 Se încearcă XX.XXX.XXX.XXX... Conectat la mail.MAILSERVER.de. Caracterul de evacuare este „^]”. 220 mail.MAILSERVER.de ESMTP Postfix`
drapel in
Deci, atunci când este conectat la serverul OpenVPN, clientul încearcă să rezolve intrarea DNS a serverului meu de e-mail și dintr-un motiv pe care nu îl înțeleg pe deplin, încearcă să se conecteze la 127.0.1.1. Dacă încerc să mă conectez direct la IP-ul serverului meu de e-mail, telnet se poate conecta corect. $ telnet XX.XXX.XXX.XXX 25 Se încearcă XX.XXX.XXX.XXX... Conectat la NAMEOFLOCALHOST. Caracterul de evacuare este „^]”. 220 mail.MAILSERVER.de ESMTP Postfix
drapel in
Deci, cum fac ca OpenVPN să nu rezolve intrarea DNS la IP-ul meu local, ci la IP-ul public? Presupun că asta va rezolva asta.
Puncte:0
drapel aq
MTG

Configurarea VPN poate fi foarte dificilă, deoarece schimbă ruta implicită normală a sistemului cu cea a serverului VPN. Serverul, la rândul său, poate face un fel de rutare sursă pentru traficul de intrare de la clientul vpn, precum și schimbarea adreselor IP de ieșire.

În concluzie:

  1. Serverul de e-mail poate fi sensibil la schimbarea acelei adrese.

  2. Serviciul VPN vă poate direcționa traficul către interfața sa publică sau fizică, blocându-vă efectiv de la serviciile interne ale VM, inclusiv suita Postfix.

  3. Funcțiile de blocare a anunțurilor pot cauza, de asemenea, probleme cu serviciile de e-mail.

Mai bine căutați opțiunile de configurare asociate ale Pihole sau încercați definitiv alte servicii VPN, de ex. servicii VPN native Linux pentru început.

drapel in
VPN-urile pot fi configurate să devină o rută implicită, dar aceasta este configurație și nu implicită.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.