Am un server cu Pi-Hole configurat pentru a bloca reclame și trackere. Clienții sunt conectați prin OpenVPN și primesc adrese din 10.8.0.0/24. OpenVPN împinge doar DNS-ul către client, iar traficul este direcționat prin gateway-ul local, dar, desigur, fiecare client de pe VPN poate contacta orice alt client prin adresele lor 10.8.0.x.
Am comandat un al doilea ipv4 pe care aș dori să îl folosesc special pentru clientul 10.8.0.4.Vreau să pot accesa ip-ul public și să expun acel client direct la internet pentru a utiliza un Nextcloud găzduit local.
Am căutat Server Fault și am găsit câteva probleme similare. Am încercat să adaug reguli de POSTROUTING și PREROUTING la iptables, dar asta nu a funcționat. În prezent, ipv4 este adăugat temporar la eth0 prin „ip addr add xx.xx.xx.xx”. dev eth0', nu tun0 (este corect?). Serverul OpenVPN este configurat exact așa cum este menționat în documentele Pi-Hole (https://docs.pi-hole.net/guides/vpn/openvpn/only-dns-via-vpn/). net.ipv4.ip_forward este activat.
Trebuie chiar să folosesc iptables? Este posibil sau recomandat să adăugați IP-ul public la o rută sau ceva de genul? Scuze dacă întrebarea sună aiurea. Sunt destul de nou în configurația OpenVPN și Route/iptables.
Acesta este primul lucru pe care l-am încercat: Redirecționează tot traficul de intrare de la un IP public secundar către o adresă IP internă folosind iptables
Regulile mele actuale pentru iptables sunt:
# Generat de xtables-save v1.8.2 pe Thu Dec 12 14:37:26 2019
*nat
:ACCEPTAREA PRE-ROUTARE [329:28209]
:INPUT ACCEPT [281:25114]
: POSTROUTING ACCEPT [17:1423]
: ACCEPT IEȘIRE [245:22126]
-A POSTOUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source xx.xx.xx.xx
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Finalizat joi, 12 decembrie 14:37:26 2019
# Generat de xtables-save v1.8.2 pe Thu Dec 12 14:37:26 2019
*filtru
:INPUT DROP [0:0]
: FORWARD ACCEPT [0:0]
: ACCEPT IEȘIRE [0:0]
-A INTRARE -i lo -j ACCEPT
-A INPUT -m stare --stare RELATED,STABLISHED -j ACCEPT
-A INTRARE -i tun0 -j ACCEPT
-A INTRARE -i tun0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INTRARE -i tun0 -p udp -m udp --dport 53 -j ACCEPT
-A INTRARE -i tun0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INTRARE -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INTRARE -i tun0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INTRARE -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INTRARE -p tcp -m tcp --dport 2202 -j ACCEPT
-A INTRARE -p tcp -m tcp --dport 1194 -j ACCEPT
-A INTRARE -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 80 -j REJECT --reject-cu icmp-port-inaccesibil
-A INPUT -p udp -m udp --dport 443 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Finalizat joi, 12 decembrie 14:37:26 2019
reguli NAT iptables:
PRERUUTARE în lanț (politica ACCEPTĂ)
target prot opt sursă destinație
INTRARE în lanț (politica ACCEPTĂ)
target prot opt sursă destinație
POSTOUTING în lanț (politica ACCEPT)
target prot opt sursă destinație
SNAT toate -- 10.8.0.0/24 !10.8.0.0/24 la:xx.xx.xx.xx
MASQUERADE toate -- oriunde oriunde
Ieșire în lanț (politica ACCEPT)
target prot opt sursă destinație
După comentariul de la NiKiZe am adăugat temporar adresa IP publică prin
ip addr add xx.xx.xx.xx dev eth0
și am introdus ambele reguli (pentru a clarifica faptul că: am exportat setul de reguli de lucru prin iptables-save, am editat ambele comenzi și l-am restaurat prin iptables-restore)
-A PREROUTING -d xx.xx.xx.xx -j DNAT --la-destinație 10.8.0.4
-A POSTOUTING -s 10.8.0.4 ! -d 10.8.0.4 -j SNAT --to-source xx.xx.xx.xx
Apoi am deschis mai multe sesiuni de terminal și am monitorizat traficul web cu tcpdump la serverul OpenVPN și serverul meu local, confirmând că traficul de intrare de la eth0 către pi.hole.http este direcționat corect către serverul meu local server.vpn.http. Dar răspunsul expiră...
Regulile mele actuale de nat sunt:
user@dns:~# iptables -t nat -vL --line-numbers
PRERUUTARE în lanț (politica ACCEPTĂ 1 pachet, 52 de octeți)
num pkts octeți target prot opt in out sursă destinație
1 0 0 DNAT all -- any any anywhere pi.hole to:10.8.0.4
INTRARE în lanț (politica ACCEPT 0 pachete, 0 octeți)
num pkts octeți target prot opt in out sursă destinație
POSTROUTING în lanț (politica ACCEPTĂ 1 pachet, 60 de octeți)
num pkts octeți target prot opt in out sursă destinație
1 0 0 SNAT toate -- orice orice server.vpn !server.vpn la:xx.xx.xx.xx <- adresă IP adăugată temporar
2 0 0 SNAT toate -- orice orice 10.8.0.0/24 !10.8.0.0/24 la:xx.xx.xx.xx <- adresa IP principală, introdusă static
3 0 0 MASQUERADE all -- orice eth0 oriunde oriunde
IEȘIRE în lanț (politica ACCEPTĂ 1 pachet, 60 de octeți)
num pkts octeți target prot opt in out sursă destinație
O alta editie:
Când adaug „src server.vpn” la tcpdump, pot vedea că nu există trafic de ieșire de la serverul local. Deci trebuie să existe fie o problemă cu configurația serverului local, fie cu regula de postrouting. Am dreptate?
După schimbarea traseului pe server.vpn conexiunea funcționează.
„route -n” Înainte de:
Tabelul de rutare IP al nucleului
Destination Gateway Genmask Flags Metric Ref Utilizare Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3
169.254.160.0 169.254.160.1 255.255.248.0 UG 0 0 0 tun1000
169.254.160.0 0.0.0.0 255.255.248.0 U 0 0 0 tun1000
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Si dupa:
Tabelul de rutare IP al nucleului
Destination Gateway Genmask Flags Metric Ref Utilizare Iface
0.0.0.0 10.8.0.1 0.0.0.0 UG 0 0 0 tun0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3
169.254.160.0 169.254.160.1 255.255.248.0 UG 0 0 0 tun1000
169.254.160.0 0.0.0.0 255.255.248.0 U 0 0 0 tun1000
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Dacă înțeleg corect acest lucru, înseamnă că FIECARE conexiune la rețea, chiar și inițiată de server.vpn, este direcționată prin VPN. Acesta nu este comportamentul anticipat. Vreau pur și simplu ca serverul să fie accesibil local și să utilizeze internetul obișnuit, direcționat local și, de asemenea, să răspundă la conexiunile direcționate de la ip-ul public pe serverul OpenVPN.
