Вот такой странный.
Каждый раз, когда я нахожусь в сети отелей, мне нравится направлять весь свой трафик через домашнюю сеть. В основном потому, что я не совсем уверен, что все мои пароли все время проходят через SSL.
Итак, у меня есть следующие настройки сервера OpenVPN:
persist-key
dev tap
keepalive 10 120
port 1194
verb 3
status openvpn-status.log
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 8.8.8.8"
persist-tun
dh dh2048.pem
cert vpnserver.crt
key vpnserver.key
tls-auth ta.key 0
ca ca.crt
proto udp
comp-lzo
cipher AES-128-CBC
ifconfig-pool-persist ipp.txt
client-to-client
Что отлично работает с этими правилами iptable: (Он тестируется, поэтому здесь есть кое-что, что на самом деле не очищено .. Но на данный момент я не могу коснуться ни одного из них, чтобы решить, какие из них должны остаться, а какие должны быть удалены, потому что я сейчас в поездке ..)
*nat
:PREROUTING ACCEPT [1152:137606]
:INPUT ACCEPT [835:107096]
:OUTPUT ACCEPT [161:11725]
:POSTROUTING ACCEPT [40:2585]
-A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
# ==
# == ROUTING
# ==
-A POSTROUTING -o enp2s0 -j MASQUERADE
# ==
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:TCP - [0:0]
:UDP - [0:0]
:fw-interfaces - [0:0]
:fw-open - [0:0]
# ==
# == BRIDGE ROUTING
# ==
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j fw-interfaces
-A FORWARD -j fw-open
-A FORWARD -j REJECT --reject-with icmp-host-unreachable
# ==
# == Accepts
# ==
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A TCP -p tcp -m tcp --dport 443 -j ACCEPT
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT
-A UDP -p udp -m udp --dport 53 -j ACCEPT
# ==
# == Forwards
# ==
-A fw-interfaces -i tap0 -j ACCEPT
# == VPN route
-A FORWARD -i enp2s0 -o tap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tap0 -o enp2s0 -j ACCEPT
# == VPN
-A INPUT -p udp -m state --state NEW,RELATED,ESTABLISHED -m udp --dport 1194 -j ACCEPT
-A OUTPUT -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 1194 -j ACCEPT
# == DNS
-A INPUT -i enp2s0 -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 53 -j ACCEPT
-A OUTPUT -o enp2s0 -p udp -m udp --dport 53 -j ACCEPT
# == WEB-outgoing
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 443 -j ACCEPT
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 80 -j ACCEPT
# == WEB-incomming
-A INPUT -p tcp -m tcp -m state --state NEW,RELATED,ESTABLISHED --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp -m state --state ESTABLISHED,RELATED --sport 80 -j ACCEPT
# ==
# == TAP0
# ==
-A INPUT -i tap0 -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 53 -j ACCEPT
-A OUTPUT -o tap0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i tap0 -p udp --dport 67 -j ACCEPT
#-t nat -A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
-A FORWARD -i tap0 -s 10.8.0.0/24 -o enp2s0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# ==
# == GENERIC
# ==
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A FORWARD -i tap0 -j ACCEPT
# ==
# == REJECTS
# ==
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT
*nat
-A POSTROUTING -s 192.168.1.0/24 -o enp2s0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
COMMIT
# Generated by iptables-save v1.4.21 on Thu Jun 5 18:54:09 2014
*mangle
:PREROUTING ACCEPT [76747:82460059]
:INPUT ACCEPT [18221:1445339]
:FORWARD ACCEPT [58437:80998106]
:OUTPUT ACCEPT [17305:8505640]
:POSTROUTING ACCEPT [75742:89503746]
COMMIT
# Completed on Thu Jun 5 18:54:09 2014
# Generated by iptables-save v1.4.21 on Thu Jun 5 18:54:09 2014
*nat
:PREROUTING ACCEPT [1152:137606]
:INPUT ACCEPT [835:107096]
:OUTPUT ACCEPT [161:11725]
:POSTROUTING ACCEPT [40:2585]
-A POSTROUTING -o enp2s0 -j MASQUERADE
COMMIT
# Completed on Thu Jun 5 18:54:09 2014
# Generated by iptables-save v1.4.21 on Thu Jun 5 18:54:09 2014
*filter
:INPUT ACCEPT [18037:1435358]
:FORWARD ACCEPT [58437:80998106]
:OUTPUT ACCEPT [17119:8490056]
-A FORWARD -i enp2s0 -o wlp3s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlp3s0 -o enp2s0 -j ACCEPT
COMMIT
# Completed on Thu Jun 5 18:54:09 2014
Это работает только потому, что трафик точно маршрутизируется через VPN.
Но ответный трафик возвращается за пределы сети VPN по какой-либо причине, а это нежелательно. Я предполагаю MASQUERADE
все линии неправильные?
Вот пример:
Но когда я выполняю трассировку, ответ возвращается за пределы VPN:
Мои маршруты в порядке, и мой DNS работает, поэтому я снова предполагаю, что собираюсь MASQUERADE
не так в iptables? Возможно, я слишком усложнил, пытаясь связать трафик от двух интерфейсов на enp2s0
(Я вырезал br0
с участием 192.168.1.0/24
просто чтобы немного сократить правила)
Изменить: вот мои маршруты (wlp3s0 = wifi):
[torxed@archie ~]$ ip route
0.0.0.0/1 via 10.8.0.1 dev tap0
default via 192.168.1.254 dev wlp3s0
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.2
109.X.X.X via 192.168.1.254 dev wlp3s0
128.0.0.0/1 via 10.8.0.1 dev tap0
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.81
Ваши правила MASQUERADE, вероятно, неверны.
Вы маскируете только трафик, идущий через enp2s0, но не через tap0. Это, по-видимому, приводит к тому, что пакеты сохраняют адрес wlp3s0 в качестве своего исходного адреса, что объясняет, почему ваши ответы приходят через него.
Итак, несколько лет спустя и немного поумнел. Я обнаружил корень проблемы. Массовое определение проблемы было лишь частично проблемой, но моя проблема заключалась в основном в неправильно диагностированном симптоме.
Итак, чтобы замаскироваться, я сделал следующее: https://unix.stackexchange.com/questions/283801/iptables-forward-traffic-to-vpn-tunnel-if-open
Это поможет вам лучше всего вместе с ip.net.ipv4.forwarding=1
в ядре.
А потом push "redirect-gateway def1 bypass-dhcp"
проверяет, действительно ли маршрут «переопределяет» шлюз по умолчанию. И убедитесь, что вы запускаете свой openvpn-client с повышенными привилегиями или позволяете ему изменять маршруты.
Наконец, моя главная проблема заключалась в том, что я использовал свой собственный whats my ip
сервис на том же сервере, что и VPN. Это заставляет сервер выполнять некоторую внутреннюю оптимизацию маршрутизации и по-прежнему сообщать мне, что я исхожу с моего IP-адреса "un-vpn: ed". Это чертовски сбивало с толку. Вот что долго чесало в затылке.
Чтобы сварить некоторые длинные iptables, я использую вот что:
iptables -t nat -A POSTROUTING -o internet0 -j MASQUERADE
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i net0 -o internet0 -j ACCEPT
Взято из вики Arch Linux для Совместное использование Интернета.