openvpn - iptables

koper97 · Post autor: **koper97** » 23 września 2016, 17:57

witam,
nie wiem jak skonfigurować iptables dla openvpn
server i klijent (openvpn) są poprawnie skonfigurowane - w celach testowych w konsoli na serverze wpisałem

Kod: Zaznacz cały

iptables -F
iptables -A INPUT ACCEPT

połączenie nawiązane w ciągu 1-2s, przydzielone ip, ping też działa
problem pojawia się oczywiście przy konfiguracji iptables
w internecie znalazłem coś takiego:

Kod: Zaznacz cały

iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT 
iptables -A INPUT -i tun+ -j ACCEPT
ptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

eth0 zamieniłem na wlan0, ale niestety połączenie nie zotaje nawiązane....
a tak wygląda obecnie moje iptables:

Kod: Zaznacz cały

#Czyszczenie regół
iptables -F
#Odrzucenie ruchu wchodzącego
iptables -P INPUT DROP
#Odrzucenie ruchu przekazywanego
iptables -P FORWARD DROP
#Akceptacja ruchu wychodzącego
iptables -P OUTPUT ACCEPT
#Akceptacja ruchu na loopback, nasze usługi muszą mieć możliwość wzajemnie się komunikować
iptables -A INPUT -i lo -j ACCEPT
#Akceptujemy pakiety powiązane z danymi których wysłanie zainicjowane było przez nasz serwer 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#chromecast:
iptables -I INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT
#Videostream:
iptables -A INPUT -p tcp --dport 5556 -j ACCEPT
iptables -A INPUT -p tcp --dport 5558 -j ACCEPT
#logowanie odrzuconych pakietów
iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

czy mógłby mi ktoś proszę powiedzieć co mam dopisać aby openvpn działał poprawnie?
Modedit: Wyniki podawaj w znacznikach code wraz z komendą wywołującą

lizard · Post autor: **lizard** » 23 września 2016, 18:54

Proponuję poczytać w sieci o przekazywaniu ruchu. Czy wiesz co oznaczają reguło, które podałeś? Ustawiasz domyślne porzucanie pakietów dla łańcucha FORWARD i nie zostawiasz w nim wyjątków dla VPN-a. Po co otwierasz porty takie, a nie inne?

Iptables nie pomogą jeśli na serwerze w /etc/sysctl.conf nie ustawisz net.ipv4.ip_forward na 1. Po tym ustawieniu wpisz w konsoli: "sysctl -w net.ipv4.ip_forward=1", aby od razu włączyć przekazywanie pakietów. Następnie wyczyść wszystkie reguły iptables i ustaw zasady domyślne na akceptowanie ruchu:

Kod: Zaznacz cały

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Na koniec włącz SNAT:

Kod: Zaznacz cały

iptables -t nat -A POSTROUTING -s <adres_sieci_VPN>/<maska_sieci_VPN> -j SNAT --to-source <adres_IP_serwera>

Dopiero jak to ruszy, to baw się w wycinanie ruchu.

koper97 · Post autor: **koper97** » 23 września 2016, 19:09

mam ustawione net.ipv4.ip_forward na 1. faktycznie muszę trochę doczytać. te reguły znalazłem tu: https://arashmilani.com/post?id=53
jutro (jak moja dziewczyna zwolni laptopa na którym odpalam ubuntu z cd i instaluję openvpn) przetestuję Twoją poradę i napisze jak efekty.

koper97 · Post autor: **koper97** » 24 września 2016, 12:06

zastosowałem (bezpośrdnio w konsoli):

Kod: Zaznacz cały

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

włączyłem też SNAT:

Kod: Zaznacz cały

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j SNAT --to-source 192.168.1.36

połączenie nawiązane bezproblemowo, ip przydzielone, ping działa

lizard · Post autor: **lizard** » 24 września 2016, 13:14

No to świetnie. Teraz możesz blokować połączenia (dopisz poniższe linir do tego, co podałem w poprzednim poście):

Kod: Zaznacz cały

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth0 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -i tun0 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -i eth0 -p udp -m udp --dport 1194 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -j LOG --log-prefix 'iptables INPUT: '
iptables -P INPUT DROP

Linię dotyczącą sieci lokalnej dostosuj do własnych warunków. Dopóki nie blokujesz przekazywania pakietów (łańcuch FORWARD), nie ma potrzeby grzebania w nim. Warto włączyć logowanie nieudanych połączeń, aby wiedzieć, co jeszcze ewentualnie odblokować lub, czy jakaś usługa nie działa z powodu reguł iptables. Informacje o nieudanych połączeniach znajdziesz w /var/log/messages (przedrostek "iptables INPUT").

Wszystkie reguły możesz zapisać do pliku: "iptables-save > plik" i przywracać je poprzez: "iptables-restore < plik". Jak zainstalujesz pakiet iptables-persistent i zapiszesz ustawienia iptables w /etc/iptables/rules.v4, to będą odtwarzane automatycznie po każdym restarcie serwera.

koper97 · Post autor: **koper97** » 25 września 2016, 14:03

użyłem tych reguł ci mi je podałeś - jedynie eth0 zamieniłem na wlan0 - połączenie nawiązane, ping też działa
w logach pojawia mi się coś takiego:

Kod: Zaznacz cały

Sep 25 13:53:04 KOPER kernel: [ 1883.413204] iptables INPUT: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=26524 DF PROTO=UDP SPT=34074 DPT=53 LEN=47

oraz

Kod: Zaznacz cały

Sep 25 13:52:58 KOPER kernel: [ 1877.666648] iptables INPUT: IN=tun0 OUT= MAC= SRC=192.168.1.36 DST=224.0.0.251 LEN=68 TOS=0x00 PREC=0x00 TTL=1 ID=53061 DF PROTO=UDP SPT=5353 DPT=5353 LEN=48

lizard · Post autor: **lizard** » 25 września 2016, 15:17

Człowiek dwa razy sprawdza, a i tak znajdzie się babol.

W drugiej regule (iptables -A INPUT -i lo) zabrakło "-j ACCEPT" i stąd ten pierwszy wpis w logu (pakiety na pętli zwrotnej były odrzucane). Już poprawiłem.

Drugi wpis sugeruje Multicast DNS. Jeśli bawisz się czyms takim, to go odblokuj:

Kod: Zaznacz cały

iptables -A INPUT -s 192.168.1.36 --sport 5353 -d 224.0.0.251 --dport 5353 -p udp -j ACCEPT

Jak rozumiem połączenia OpenVPN działają i możesz przeglądać sieć lokalną z zewnątrz?

koper97 · Post autor: **koper97** » 26 września 2016, 19:11

server i klient znajdują się w tej samej sieci,
jest połączenie, ping, ale po chwili dostaje taki komunikat:
TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

log z klienta wygląda tak:

Kod: Zaznacz cały

Mon Sep 26 15:42:47 2016 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Mon Sep 26 15:42:47 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 26 15:42:47 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 26 15:42:47 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]
Mon Sep 26 15:42:47 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mon Sep 26 15:42:47 2016 UDPv4 link local (bound): [undef]
Mon Sep 26 15:42:47 2016 UDPv4 link remote: [AF_INET]192.168.1.37:1194
Mon Sep 26 15:42:47 2016 TLS: Initial packet from [AF_INET]192.168.1.37:1194, sid=c20d12c1 e53683c8
Mon Sep 26 15:42:47 2016 VERIFY OK: depth=1, C=NL, ST=NH, L=DeRijp, O=Fort-Koper, OU=Koper, CN=server, name=Server, emailAddress=koper97@o2.pl
Mon Sep 26 15:42:47 2016 VERIFY OK: nsCertType=SERVER
Mon Sep 26 15:42:47 2016 VERIFY OK: depth=0, C=NL, ST=NH, L=DeRijp, O=Fort-Koper, OU=Koper, CN=server, name=Server, emailAddress=koper97@o2.pl
Mon Sep 26 15:42:49 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1562', remote='link-mtu 1558'
Mon Sep 26 15:42:49 2016 WARNING: 'mtu-dynamic' is present in local config but missing in remote config, local='mtu-dynamic'
Mon Sep 26 15:42:49 2016 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Sep 26 15:42:49 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 26 15:42:49 2016 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon Sep 26 15:42:49 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 26 15:42:49 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Mon Sep 26 15:42:49 2016 [server] Peer Connection Initiated with [AF_INET]192.168.1.37:1194
Mon Sep 26 15:42:52 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon Sep 26 15:42:52 2016 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,redirect-gateway local def1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.0.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.0.0.5 10.0.0.6'
Mon Sep 26 15:42:52 2016 OPTIONS IMPORT: timers and/or timeouts modified
Mon Sep 26 15:42:52 2016 OPTIONS IMPORT: --ifconfig/up options modified
Mon Sep 26 15:42:52 2016 OPTIONS IMPORT: route options modified
Mon Sep 26 15:42:52 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Sep 26 15:42:52 2016 ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=wlp6s0 HWADDR=00:1f:e1:9f:fc:30
Mon Sep 26 15:42:52 2016 TUN/TAP device tun0 opened
Mon Sep 26 15:42:52 2016 TUN/TAP TX queue length set to 100
Mon Sep 26 15:42:52 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Sep 26 15:42:52 2016 /sbin/ip link set dev tun0 up mtu 1500
Mon Sep 26 15:42:52 2016 /sbin/ip addr add dev tun0 local 10.0.0.5 peer 10.0.0.6
Mon Sep 26 15:42:52 2016 /sbin/ip route add 0.0.0.0/1 via 10.0.0.6
Mon Sep 26 15:42:52 2016 /sbin/ip route add 128.0.0.0/1 via 10.0.0.6
Mon Sep 26 15:42:52 2016 /sbin/ip route add 192.168.1.0/24 via 10.0.0.6
Mon Sep 26 15:42:52 2016 /sbin/ip route add 10.0.0.1/32 via 10.0.0.6
Mon Sep 26 15:42:52 2016 GID set to nogroup
Mon Sep 26 15:42:52 2016 UID set to nobody
Mon Sep 26 15:42:52 2016 Initialization Sequence Completed
Mon Sep 26 15:44:52 2016 [server] Inactivity timeout (--ping-restart), restarting
Mon Sep 26 15:44:52 2016 SIGUSR1[soft,ping-restart] received, process restarting
Mon Sep 26 15:44:52 2016 Restart pause, 2 second(s)
Mon Sep 26 15:44:54 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]
Mon Sep 26 15:44:54 2016 UDPv4 link local (bound): [undef]
Mon Sep 26 15:44:54 2016 UDPv4 link remote: [AF_INET]192.168.1.37:1194
Mon Sep 26 15:45:54 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Sep 26 15:45:54 2016 TLS Error: TLS handshake failed
Mon Sep 26 15:45:54 2016 SIGUSR1[soft,tls-error] received, process restarting
Mon Sep 26 15:45:54 2016 Restart pause, 2 second(s)
Mon Sep 26 15:45:56 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]
Mon Sep 26 15:45:56 2016 UDPv4 link local (bound): [undef]
Mon Sep 26 15:45:56 2016 UDPv4 link remote: [AF_INET]192.168.1.37:1194
Mon Sep 26 15:46:56 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

na tronie openvpn.net znalazłem możliwe przyczyny:
A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.

lizard · Post autor: **lizard** » 26 września 2016, 20:20

Kod: Zaznacz cały

Mon Sep 26 15:42:52 2016 Initialization Sequence Completed
Mon Sep 26 15:44:52 2016 [server] Inactivity timeout (--ping-restart), restarting
Mon Sep 26 15:44:52 2016 SIGUSR1[soft,ping-restart] received, process restarting
Mon Sep 26 15:44:52 2016 Restart pause, 2 second(s)

Po dwóch minutach nastąpiło rozłączenie z powodu braku aktywności. Firewall nie ma już tutaj nic do rzeczy. Pokaż konfigurację serwera i klienta oraz logi ich z tego samego połączenia.

koper97 · Post autor: **koper97** » 27 września 2016, 18:34

masz rację to nie wina firewall'a. W konfiguracji serwera miałem:

Kod: Zaznacz cały

client-config-dir firma

zamiast:

Kod: Zaznacz cały

client-config-dir /etc/openvpn/firma

wszystkie klucze i certyfikaty miały podane ścieżkę bezwzględną, za wyjątkiem lokalizacji folderu ze specjalnymi ustawieniami dla klienta,
co powodowało że plik nie był poprawnie wczytywany - naprowadziły mnie na to logi servera. Po wprowadzeniu poprawki wszystko działa,
IP przydzielone, ping, nie wyrzuca już żadnych błędów, nawet działa internet w tunelu

Dzięki za pomoc i poświęcony czas

openvpn - iptables

openvpn - iptables

Re: openvpn - iptbles

Re: openvpn - iptbles

Re: openvpn - iptables

Re: openvpn - iptables

Re: openvpn - iptables

Re: openvpn - iptables

Re: openvpn - iptables

Re: openvpn - iptables

Re: openvpn - iptables