OpenVPN server na Turrisu

[beer]

Zde (http://www.netfilter.org/documentation/HOWTO/cz/NAT-HOWTO-6.html) se píše

Pro masquerading nemusíš explicitně určovat zdrojovou adresu: použije se zdrojová adresa rozhraní, ze kterého odchází paket.

Byl by tedy takovíto soubor OK?:

Kód [Vybrat] Rozbalit


# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
iptables -t nat -A prerouting_wan -p udp --dport 1194 -j ACCEPT
iptables -A input_wan -p udp --dport 1194 -j ACCEPT
iptables -t nat -A prerouting_lan -p udp --dport 1194 -j ACCEPT
iptables -A input_lan -p udp --dport 1194 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 --dport 1194 -j MASQUERADE
iptables -I INPUT -i tun+ -j ACCEPT
iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I OUTPUT -o tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT


[Reklama]

[beer]

Kód [Vybrat] Rozbalit


root@turris:~# iptables -t nat -A POSTROUTING -s 192.168.100.0/24 --dport 1194 -j MASQUERADE 

iptables v1.4.21: unknown option "--dport"                                                   

Try `iptables -h' or 'iptables --help' for more information


[beer]

Tak jsem ručně zkusil přes ssh přidat pravidlo

Kód [Vybrat] Rozbalit

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o lan -j MASQUERADE

a klient stejně vypisuje chyby

Kód [Vybrat] Rozbalit

Tue Jan 19 12:11:29 2016 OpenVPN 2.3.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS

11] [MH] [IPv6] built on Jul  8 2015                                                         

Tue Jan 19 12:11:29 2016 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08               

Tue Jan 19 12:11:29 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]               

Tue Jan 19 12:11:30 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull,

or --up-delay                                                                                 

Tue Jan 19 12:11:30 2016 UDPv4 link local: [undef]                                           

Tue Jan 19 12:11:30 2016 UDPv4 link remote: [AF_INET]89.177.109.252:1194                     

Tue Jan 19 12:11:30 2016 TCP/UDP: Incoming packet rejected from [AF_INET]192.168.1.1:1194[2],

expected peer address: [AF_INET]89.177.109.252:1194 (allow this incoming source address/port b

y removing --remote or adding --float)                                                       

Tue Jan 19 12:11:32 2016 TCP/UDP: Incoming packet rejected from [AF_INET]192.168.1.1:1194[2],

expected peer address: [AF_INET]89.177.109.252:1194 (allow this incoming source address/port b

y removing --remote or adding --float)                                                       

Tue Jan 19 12:11:32 2016 TCP/UDP: Incoming packet rejected from [AF_INET]192.168.1.1:1194[2],

expected peer address: [AF_INET]89.177.109.252:1194 (allow this incoming source address/port b

y removing --remote or adding --float)                                                       

Tue Jan 19 12:11:36 2016 event_wait : Interrupted system call (code=4)                       

Tue Jan 19 12:11:36 2016 SIGINT[hard,] received, process exiting   

[beer]

na serveru

Kód [Vybrat] Rozbalit


cat /tmp/openvpn-status.log                                                   

OpenVPN CLIENT LIST                                                                           

Updated,Tue Jan 19 12:29:57 2016                                                             

Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since                           

ROUTING TABLE                                                                                 

Virtual Address,Common Name,Real Address,Last Ref                                             

GLOBAL STATS                                                                                 

Max bcast/mcast queue length,0                                                               

END   

/etc/openvpn/ipp.txt je pořád prázdný.

[pistelak]

Za litr ti to nastavim.

[Reklama]

[beer]

Za litr ti to nastavim.

Tvou nabídku považuji za reklamu. Až si nebudeš s něčím vědět rady, tak ti odpovím zřejmě v podobném duchu.

[pistelak]

Tak za dva.

[trubicoid2]

ja myslim, ze ten klient se na server vubec nedostane

to routovani prijde na radu az potom, az se spojis

neco proste vadi v ceste, mas povoleny ve fw port 1194 udp? taky muzes zkusit openvpn na tcp, ma to trochu nevyhody, ale nektery site udp vic blokuji

navic se zda, ze klient vola 89.177.109.252:1194 udp, ale odpoved mu leze z 192.168.1.1:1194, coz je zablokovany

ty to delas ve vnitrni siti? proc teda v klientovi nevolas to 192.168.1.1:1194?

jeste jsem nasel navod na ufw s openvpn tu: https://www.gaggl.com/2013/04/openvpn-forward-all-client-traffic-through-tunnel-using-ufw/

ale prvne to rozjed bez firewallu

[beer]

ja myslim, ze ten klient se na server vubec nedostane

to routovani prijde na radu az potom, az se spojis

neco proste vadi v ceste, mas povoleny ve fw port 1194 udp? taky muzes zkusit openvpn na tcp, ma to trochu nevyhody, ale nektery site udp vic blokuji

navic se zda, ze klient vola 89.177.109.252:1194 udp, ale odpoved mu leze z 192.168.1.1:1194, coz je zablokovany

ty to delas ve vnitrni siti? proc teda v klientovi nevolas to 192.168.1.1:1194?

jeste jsem nasel navod na ufw s openvpn tu: https://www.gaggl.com/2013/04/openvpn-forward-all-client-traffic-through-tunnel-using-ufw/

ale prvne to rozjed bez firewallu

Ve FW kde, na turrisu, nebo v Ubuntu? V ubuntu je povolené přes ufw, turris a ubuntu jsou propojeni lan kabelem, v konfiguračním souboru je moje doména, která má nastavenou veřejnou ip adresu od poskytovatele - to je i veřejná ip adresa turrisu. Odpověď je z lokální ip adresy turrisu 192.168.1.1, kterou má nastavenou pro lan. To myslím, že je normální. Další klienti by měli mít stejný konfigurační soubor + jiné certifikáty a pokud budou mimo domácí wifi, tak budou dostávat odpověď z veřejné ip adresy.

Přece nebudu na klientech měnit konfigurační soubory dle toho, jestli jsem ve vnitřní síti, nebo jestli jsem venku...

[beer]

Tak pokud v configu na klientovi nastavím lokální ip adresu turrise místo domény, tak to asi funguje, ale píše to chyby. To je opravdu nutné při změně sítě upravovat vždycky konfigurák?

Kód [Vybrat] Rozbalit


Tue Jan 19 14:55:40 2016 OPTIONS IMPORT: route options modified                               

Tue Jan 19 14:55:40 2016 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=enp4s0 HWADDR=00:1a:a0:

36:50:9b                                                                                     

Tue Jan 19 14:55:40 2016 TUN/TAP device tun0 opened                                           

Tue Jan 19 14:55:40 2016 TUN/TAP TX queue length set to 100                                   

Tue Jan 19 14:55:40 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0               

Tue Jan 19 14:55:40 2016 /sbin/ip link set dev tun0 up mtu 1500                               

Tue Jan 19 14:55:40 2016 /sbin/ip addr add dev tun0 local 192.168.100.6 peer 192.168.100.5   

Tue Jan 19 14:55:40 2016 /sbin/ip route add 192.168.1.1/32 dev enp4s0                         

Tue Jan 19 14:55:40 2016 /sbin/ip route add 0.0.0.0/1 via 192.168.100.5                       

Tue Jan 19 14:55:40 2016 /sbin/ip route add 128.0.0.0/1 via 192.168.100.5                     

Tue Jan 19 14:55:40 2016 /sbin/ip route add 192.168.100.1/32 via 192.168.100.5               

Tue Jan 19 14:55:40 2016 GID set to nogroup                                                   

Tue Jan 19 14:55:40 2016 UID set to nobody                                                   

Tue Jan 19 14:55:40 2016 Initialization Sequence Completed                                   

Tue Jan 19 14:55:50 2016 Bad LZO decompression header byte: 42                               

Tue Jan 19 14:56:00 2016 Bad LZO decompression header byte: 42                               

Tue Jan 19 14:56:10 2016 Bad LZO decompression header byte: 42                               

Tue Jan 19 14:56:20 2016 Bad LZO decompression header byte: 42                               

Tue Jan 19 14:56:30 2016 Bad LZO decompression header byte: 42                               

Tue Jan 19 14:56:40 2016 Bad LZO decompression header byte: 42

Jakmile nastavím lokální adresu, přestane fungovat na PC internet - nejde pingnout ani na 8.8.8.8

[beer]

Jakmile nastavím lokální adresu, přestane fungovat na PC internet - nejde pingnout ani na 8.8.8.8

Přitom nastavuji vzdáleně - přes ssh spojení na turris a z turrise do pc, a spojení mi nespadne, jako by se provoz (třeba ten ping na 8.8.8. přesměroval přes vpn a tam skončil - z turrise se nedostal ven.

[trubicoid2]

no tak hura, uz jsi spojeny a mas ip 192.168.100.6

vono jako vzdycky budes pouzivat tu verejnou ip adresu, asi tezko budes krome ted pokusu se doma pripojovat do domaci vpn, ne?

takze bys mel spravne zkouset z nejake vzdalene masiny se pripojovat do turise no

presne nevim, proc te to vykopne, kdyz pouzijes verejnou ip a odpoved je lokalni ip, ja to doma nezkousel

tak ted teda spojeni je, IP je, jen jeste v turrisu asi neni udelany to routovani

Kód [Vybrat] Rozbalit

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j SNAT --to-source 192.168.1.1
nebo tak nejak

[beer]

No, má představa je taková, že klient bude mít vždy stejnou konfiguraci, třeba notebook, chytrý telefon, atd a provoz ať už bude z domova nebo z venku půjde přes vpn, aby se zvýšilo bezpečí - takže například z hospody na veřejné wifi budu moci využívat skutečně bezpečného internetu, protože provoz by byl protunelovaný přes vpn zabezpečeně. V zahraničí bych si mohl pustit třeba online tv přes http://horizon.tv, kde je omezení na české ip adresy a pod. Takže bych rád vychytal univerzální řešení.

Těm iptables bych se raději vyhnul, turris by to měl mít možnost konfigurovat v /etc/config/firewall a v /etc/config/network, což jsou standardní konfigurační soubory, které to používá, tak jen vědět, jak přesně, aby to fungovalo, a ten tunelovaný provoz je popsaný zde: https://wiki.openwrt.org/doc/howto/vpn.openvpn#route_all_client_traffic_through_the_tunnel, akorát tam to nastavují přes uci, čemu já nerozumím a možná díky kombinaci různých návodů mám v těch konfiguračních souborech bordel, asi by bylo nejlepší, kdyby se někdo podíval na ty soubory a řekl mi, co tam mám kde nastavit. Vědět, jak to udělat přes iptables je fajn, ale rád bych to měl v těch konfigurácíh správně a nehackoval své předchozí chyby v konfiguraci přes iptables....

[Trubicoid2]

Akurat z domova, kde sedi turris, ti VPN nic nepomuze a zadne bezpečí ti nezvysi. Venku, v hospode, na free Wi-Fi jo, pustis openvpn a je to. Doma ne, tam ho mas vypnuty, protože je to na prd.

V navodech je zmatek, vono totiž to VPN muze fungovat jako bridge, tedy ve stejné podsíti. To nechceš. Chceš nat a forward. Iptables potřebuješ. Ten můj příkaz to asi řeší. Konfiguraci openwrt nevím

[beer]

tak už se mi klient spustí i s doménou, musel jsem přidat do konfiguráku

Kód [Vybrat] Rozbalit

float

Pořád zůstává ale ta chyba

Kód [Vybrat] Rozbalit

Bad LZO decompression header byte: 42, tun0 získá adresu 192.168.100.4, ale neukazuje adresu vzdáleného konce, měla by být vidět v ifconfig? Jak vyřešit tu chybu? Zkusil jsem vypnout kompresy jak na serveru tak na klientovi a chyba nezmyzela. Nemůže být problém třeba v MTU?