rafipl86 0 Zgłoś post Napisano Styczeń 15, 2017 (edytowany) VPS w netdc.pl - Debian 7.4 na OpenVZChciałem postawić serwer VPN do celów monitoring CCTV. Niby się udało, połączenie jest, jednakże brak dostępu do internetu na kliencie (jest dostęp jedynie do stron/zasobów znajdujących się na tym samym serwerze). Testowałem na kliencie w Windowsie oraz Androidzie. DNSy stron tak jakby zostały znajdowane, bo pingowałem różne strony i zawsze wyszukiwano DNS, ale żadne pakiety nie przechodziły. Spędziłem już dwa dni próbując różnych rozwiązań i nic Konfiguracja serwera: port 1194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key dh /etc/openvpn/dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" client-to-client keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log log-append openvpn.log verb 3 W pliku rc.log dodane: mkdir -p /dev/net mknod /dev/net/tun c 10 200 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE service openvpn restart rules.v4 IPTABLES: -A INPUT -i tun0 -p tcp -m tcp --dport 1194 -j ACCEPT -A FORWARD -i tun+ -o eth0 -j ACCEPT -A FORWARD -i eth0 -o tun+ -j ACCEPT Konfiguracja klienta client dev tun proto udp remote (ADRES IP SERWERA) port 1194 resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun ns-cert-type server comp-lzo verb 3 <ca> -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- xxx -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- xxx -----END PRIVATE KEY----- </key> w /proc/sys/net/ipv4/ip_forward wartość zmieniona na 1 Edytowano Styczeń 15, 2017 przez rafipl86 (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
kafi 2425 Zgłoś post Napisano Styczeń 15, 2017 Problem wynika z braku poprawnej translacji adresów na serwerze - nie masz wyjścia na świat. Przyczyny mogą leżeć w tym, że: 1. Na OpenVZ masz raczej interfejs venet0 a nie eth0 2. Na OpenVZ średnio działa target MASQUERADE. Do zastąpienia przez SNAT i jawne podanie adresu wyjściowego. Z resztą dla mnie osobiście bezsensownym jest przekierowywanie całości ruchu przez ten VPN. Nie będzie efektywniej zrobić push route jedynie wybranych tras (tylko do sieci z rejestratorem i sieci z kamerami)? Udostępnij ten post Link to postu Udostępnij na innych stronach
rafipl86 0 Zgłoś post Napisano Styczeń 15, 2017 (edytowany) Faktycznie venet0 venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:127.0.0.2 P-t-P:127.0.0.2 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:1271 errors:0 dropped:0 overruns:0 frame:0 TX packets:784 errors:0 dropped:164 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:179969 (175.7 KiB) TX bytes:503138 (491.3 KiB) venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:(VPS_IP) P-t-P:(VPS_IP) Bcast:(VPS_IP) Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 Zmieniłem reguły iptables na: -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 10.8.0.0/24 -j ACCEPT -A FORWARD -j REJECT -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to-source (VPS_IP) ...jednakże nic to dalej nie pomaga i brak wyjścia na świat. czy tak powinno wyglądać iptables -L -n -v ? Chain INPUT (policy ACCEPT 1870 packets, 245K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 215 packets, 20954 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1262 packets, 686K bytes) pkts bytes target prot opt in out source destination Trasy na kliencie: Aktywne trasy: Miejsce docelowe w sieci Maska sieci Brama Interfejs Metryka 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.101 20 0.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 276 10.8.0.1 255.255.255.255 10.8.0.5 10.8.0.6 276 10.8.0.4 255.255.255.252 On-link 10.8.0.6 276 10.8.0.6 255.255.255.255 On-link 10.8.0.6 276 10.8.0.7 255.255.255.255 On-link 10.8.0.6 276 VPS_IP 255.255.255.255 192.168.1.1 192.168.1.101 276 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 128.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 276 192.168.1.0 255.255.255.0 On-link 192.168.1.101 276 192.168.1.101 255.255.255.255 On-link 192.168.1.101 276 192.168.1.255 255.255.255.255 On-link 192.168.1.101 276 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.1.101 276 224.0.0.0 240.0.0.0 On-link 10.8.0.6 276 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.1.101 276 255.255.255.255 255.255.255.255 On-link 10.8.0.6 276 Nie chce skupiać się tylko na wybranych trasach, gdyż sprawa nie jest taka prosta. Póki co potrzebuje klienta smartfon puścić przez VPN, gdyż Play zablokował mu możliwość łączenia się z chmurą P2P od kamer kamerami. Dlatego próbuje zaradzić. Jeśli nie pomoże, to wtedy będę stawiał drugiego klienta VPN przy rejestratorze. Edytowano Styczeń 15, 2017 przez rafipl86 (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
rafipl86 0 Zgłoś post Napisano Styczeń 15, 2017 tcpdump -nnel -i venet0 host 8.8.8.8: 00:26:13.250425 Out ethertype IPv4 (0x0800), length 72: 10.8.0.6.2896 > 8.8.8.8.53: 13970+ A? mmvsedniqt. (28) 00:26:13.260904 Out ethertype IPv4 (0x0800), length 69: 10.8.0.6.11049 > 8.8.8.8.53: 20186+ A? sapkcyv. (25) 00:26:13.280809 Out ethertype IPv4 (0x0800), length 73: 10.8.0.6.19483 > 8.8.8.8.53: 14884+ A? qpcrudawimn. (29) 00:26:17.394970 Out ethertype IPv4 (0x0800), length 80: 10.8.0.6.29702 > 8.8.8.8.53: 23994+ AAAA? graph.facebook.com. (36) 00:26:22.599001 Out ethertype IPv4 (0x0800), length 78: 10.8.0.6.3706 > 8.8.8.8.53: 13050+ AAAA? www.dahuap2p.com. (34) 00:26:22.601168 Out ethertype IPv4 (0x0800), length 90: 10.8.0.6.22037 > 8.8.8.8.53: 4633+ AAAA? appservices.easy4ipcloud.com. (46) Udostępnij ten post Link to postu Udostępnij na innych stronach
volt123 3 Zgłoś post Napisano Styczeń 16, 2017 Może nie w temacie, ale ostatnio miałem podobny problem na VPSie, gdzie host zablokował możliwości zmian IPtables. Fajnie wtedy zadziałało oprogramowanie do VPNa SoftEther - http://www.softether.org/ Jest bajecznie prosty w konfiguracji i jak chcesz na szybko coś postawić, to może Ci to pomóc - https://www.digitalocean.com/community/tutorials/how-to-setup-a-multi-protocol-vpn-server-using-softether Prócz OpenVPNa wspiera też L2TP/IPSec, więc nie potrzebujesz na urządzeniu instalować żadnej appki, bo android w standardzie to wspiera. Udostępnij ten post Link to postu Udostępnij na innych stronach
rafipl86 0 Zgłoś post Napisano Styczeń 16, 2017 (edytowany) Problem rozwiązany. Jak się okazało reguły IPTABLES zapisane w rules.v4 nie były ładowane. nie ładowały się również z pliku rc.local. Dopiero wpisanie ich do pliku .profile gdzie będą ładowane przy starcie serwera poskutkowało i wszystko działa jak należy! Edytowano Styczeń 16, 2017 przez rafipl86 (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
