광고 및 추적기를 차단하도록 구성된 Pi-Hole 서버가 있습니다. 클라이언트는 OpenVPN을 통해 연결되며 10.8.0.0/24에서 주소를 가져옵니다. OpenVPN은 DNS를 클라이언트에만 푸시하고 트래픽은 로컬 게이트웨이를 통해 라우팅되지만 VPN의 모든 클라이언트는 10.8.0.x 주소를 통해 다른 모든 클라이언트에 연결할 수 있습니다.
클라이언트 10.8.0.4에 특별히 사용하고 싶은 두 번째 ipv4를 주문했습니다. 공용 IP에 액세스하고 해당 클라이언트를 인터넷에 직접 노출하여 로컬로 호스팅되는 Nextcloud를 사용할 수 있기를 원합니다.
Server Fault를 검색하여 비슷한 문제를 발견했습니다. iptables에 POSTROUTING 및 PREROUTING 규칙을 추가하려고 시도했지만 제대로 작동하지 않았습니다. ipv4는 현재 'ip addr add xx.xx.xx.xx'를 통해 eth0에 일시적으로 추가됩니다. tun0이 아니라 dev eth0'입니다(맞나요?). OpenVPN 서버는 Pi-Hole 문서(https://docs.pi-hole.net/guides/vpn/openvpn/only-dns-via-vpn/). net.ipv4.ip_forward가 활성화되었습니다.
iptables도 사용해야 하나요? 공개 IP를 경로 등에 추가하는 것이 가능하거나 권장됩니까? 질문이 어리석게 들렸다면 죄송합니다. 저는 OpenVPN 및 Route/iptables 구성을 처음 접했습니다.
그것이 내가 시도한 첫 번째 것입니다:iptables를 사용하여 보조 공용 IP에서 들어오는 모든 트래픽을 내부 IP 주소로 리디렉션
내 현재 iptables 규칙은 다음과 같습니다.
# Generated by xtables-save v1.8.2 on Thu Dec 12 14:37:26 2019
*nat
:PREROUTING ACCEPT [329:28209]
:INPUT ACCEPT [281:25114]
:POSTROUTING ACCEPT [17:1423]
:OUTPUT ACCEPT [245:22126]
-A POSTROUTING -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
# Completed on Thu Dec 12 14:37:26 2019
# Generated by xtables-save v1.8.2 on Thu Dec 12 14:37:26 2019
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i tun0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2202 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 80 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p udp -m udp --dport 443 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Thu Dec 12 14:37:26 2019
iptables NAT 규칙:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 10.8.0.0/24 !10.8.0.0/24 to:xx.xx.xx.xx
MASQUERADE all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
NiKiZe의 댓글 이후 임시로 공용 IP 주소를 추가했습니다.
ip addr add xx.xx.xx.xx dev eth0
두 규칙을 모두 입력했습니다(명확히 설명하기 위해: iptables-save를 통해 작업 규칙 세트를 내보냈고, 두 명령을 모두 편집하고 iptables-restore를 통해 복원했습니다).
-A PREROUTING -d xx.xx.xx.xx -j DNAT --to-destination 10.8.0.4
-A POSTROUTING -s 10.8.0.4 ! -d 10.8.0.4 -j SNAT --to-source xx.xx.xx.xx
그런 다음 여러 터미널 세션을 열고 OpenVPN 서버와 로컬 서버에서 tcpdump를 사용하여 웹 트래픽을 모니터링하여 eth0에서 pi.hole.http로 들어오는 트래픽이 로컬 서버 server.vpn.http로 올바르게 라우팅되는지 확인했습니다. 하지만 답변 시간이 초과되었습니다 ...
내 현재 NAT 규칙은 다음과 같습니다.
user@dns:~# iptables -t nat -vL --line-numbers
Chain PREROUTING (policy ACCEPT 1 packets, 52 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DNAT all -- any any anywhere pi.hole to:10.8.0.4
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 SNAT all -- any any server.vpn !server.vpn to:xx.xx.xx.xx <- temporarily added ip address
2 0 0 SNAT all -- any any 10.8.0.0/24 !10.8.0.0/24 to:xx.xx.xx.xx <- main ip address, statically entered
3 0 0 MASQUERADE all -- any eth0 anywhere anywhere
Chain OUTPUT (policy ACCEPT 1 packets, 60 bytes)
num pkts bytes target prot opt in out source destination
또 다른 편집: 'src server.vpn'을 tcpdump에 추가하면 로컬 서버에서 아웃바운드 트래픽이 없다는 것을 알 수 있습니다. 따라서 로컬 서버 구성이나 사후 라우팅 규칙에 문제가 있을 수 있습니다. 나 맞아?
server.vpn에서 경로를 변경하면 연결이 작동합니다. 'route -n' 이전:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use 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
그리고 그 이후:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use 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
내가 이것을 올바르게 이해한다면, 이는 server.vpn에 의해 시작된 모든 네트워크 연결이 VPN을 통해 라우팅된다는 것을 의미합니다. 이는 예상된 동작이 아닙니다. 저는 단순히 서버에 로컬로 액세스할 수 있고 일반 로컬로 라우팅된 인터넷을 사용하고 OpenVPN 서버의 공용 IP에서 라우팅된 연결에 응답하기를 원합니다.