Re: VPN za maskaradą?
Dnia 2012-02-21, o godz. 12:06:22 "Sub" napisał(a): > Nie mogę sobie poradzić z zagadnieniem jak w tytule. Z tego co > wyczytałem w sieci istnieje faktycznie kłopot z przepuszczaniem ruchu > VPN przez maskaradę. A jednak przecież multum sieci stoi za maskaradą > i tyle samo multum ludzi korzysta z vpnu bedac w takiej konfiguracji. > A konfiguracja jest najprostrza. > 1. Router VPN centrala (sprzęt, nie > 2. Siec Internet > 3. Router z maskaradą Debian > 4. Sieć lokalna z klientami wdzwanianymi pod Windows. Co to za VPN? IPSEC/L2TP, IPSEC/PPTP, jakieś rozwiązanie Cisco? Czy ,,router VPN'' wspiera NAT-T? Czy prywatne adresy sieci lokalnej nie pokrywają się z adresami lokalnymi używanymi przez ,,router VPN''? > Problem polega na tym, że wdzwaniany vpn klient z windows nie potrafi > przejść choćby autoryzacji (lohgin/hasło), połączenie nie zestawia > się. Ten sam klient przepięty na numery IP publiczne które omijają > maskowanie wdzwania > się bez problemu. Komunikat i numer błędu? Windows XP czy nowszy? Czy klient wyposażony jest w zaporę sieciową inną niż dostarczona przez Microsoft? > Z tego co udało mi się znaleźć na sieci wynika, że maskarada w jakiś > sposób modyfikuje pakiety vpnu przez co występują kłopoty ze spieciem > takiego tunelu. Jest sporo opisów rozwiązań w oparciu o Swany ale sa > to rozwiązania punkt punkt (w obu lokalizacjach są stawiane vpny na > linuxie i nie przechodzą przez maskaradę). Co pojawia się w logach usługi VPN? Co mówią logi netfilter na Debianie? > Znalazłem na necie wpisy do maskarady które przepuszaczały by poza > maskaradą ruch na poszczególnych portach wykorzystywanych przy VPN: > > iptables --append INPUT --protocol AH --in-interface eth0 --jump > ACCEPT iptables --append INPUT --protocol ESP --in-interface eth0 > --jump ACCEPT iptables --append INPUT --protocol UDP --source-port > 500 --destination-port 500 --in-interface eth0 --jump ACCEPT > iptables --append INPUT --protocol UDP --source-port 4500 > --destination-port 4500 --in-interface eth0 --jump ACCEPT Powyższe wpisy mają jedynie sens gdy na hoście robiącym NAT odpaliłeś serwer IKE (openswan, strongswan, racoon itd.) i chcesz przepuszczać przychodzące do niego połączenia. Użyj łańcucha FORWARD. Coś w stylu: -A FORWARD -p udp --dport 500 -A FORWARD -p udp --dport 4500 -A FORWARD -p ah -A FORWARD -p esp do tego `-j ACCEPT' oraz odpowiednie `-i' oraz `-o'. -- Krzysztof Kaczmar -- To UNSUBSCRIBE, email to debian-user-polish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120221130545.68ce15ac@char.neurosoft.local
Re: VPN za maskaradą?
On Tue, 21 Feb 2012 12:06:22 +0100 "Sub" wrote: > Witam, > > Nie mogę sobie poradzić z zagadnieniem jak w tytule. Z tego co > wyczytałem w sieci istnieje faktycznie kłopot z przepuszczaniem ruchu > VPN przez maskaradę. A jednak przecież multum sieci stoi za maskaradą > i tyle samo multum ludzi korzysta z vpnu bedac w takiej konfiguracji. > > A konfiguracja jest najprostrza. > 1. Router VPN centrala (sprzęt, nie Jeśli to IPsec to powienien mieć opcje: transport/tunnel mode. Transport mode służy do polączeń host-host (hash pakietu zawiera ip/port stąd NAT podmieniając je 'psuje' pakiet) - tunnel mode służy do łączenia siec- siec czy router - zdalny dostęp - opcja dla ciebie. Jest tez cos takiego jak NAT-T - ale tym się nie bawiłem nigdy. -- Jasiek -- To UNSUBSCRIBE, email to debian-user-polish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120221125237.55862b90@klapek
Re: VPN za maskaradą?
jak dasz radę to spróbuj zmienić UDP na TCP to pierwsze co mi na myśl przychodzi... TG On 21.02.2012 12:06, Sub wrote: Witam, Nie mogę sobie poradzić z zagadnieniem jak w tytule. Z tego co wyczytałem w sieci istnieje faktycznie kłopot z przepuszczaniem ruchu VPN przez maskaradę. A jednak przecież multum sieci stoi za maskaradą i tyle samo multum ludzi korzysta z vpnu bedac w takiej konfiguracji. A konfiguracja jest najprostrza. 1. Router VPN centrala (sprzęt, nie 2. Siec Internet 3. Router z maskaradą Debian 4. Sieć lokalna z klientami wdzwanianymi pod Windows. Problem polega na tym, że wdzwaniany vpn klient z windows nie potrafi przejść choćby autoryzacji (lohgin/hasło), połączenie nie zestawia się. Ten sam klient przepięty na numery IP publiczne które omijają maskowanie wdzwania się bez problemu. Z tego co udało mi się znaleźć na sieci wynika, że maskarada w jakiś sposób modyfikuje pakiety vpnu przez co występują kłopoty ze spieciem takiego tunelu. Jest sporo opisów rozwiązań w oparciu o Swany ale sa to rozwiązania punkt punkt (w obu lokalizacjach są stawiane vpny na linuxie i nie przechodzą przez maskaradę). Znalazłem na necie wpisy do maskarady które przepuszaczały by poza maskaradą ruch na poszczególnych portach wykorzystywanych przy VPN: iptables --append INPUT --protocol AH --in-interface eth0 --jump ACCEPT iptables --append INPUT --protocol ESP --in-interface eth0 --jump ACCEPT iptables --append INPUT --protocol UDP --source-port 500 --destination-port 500 --in-interface eth0 --jump ACCEPT iptables --append INPUT --protocol UDP --source-port 4500 --destination-port 4500 --in-interface eth0 --jump ACCEPT tudzież próbowałem wykluczyć z maskarady protokoły odpowiedzialne za vpn: iptables -t nat -I POSTROUTING 1 -p 50 -j ACCEPT. iptables -t nat -I POSTROUTING 1 -p 51 -j ACCEPT. Bez skutku niestety :( Połączenia wdzwaniane przez klientów stojących za natem są przecież popularne. Ja nie mogę sobie dać z tym rady. Na każdym routerku za grosze jest opcja "VPN pass through". Ale jak to zrobić na Linuxie? Będę wdzięczny za każdą pomocną dłoń. Pozdrawiam, G.M. -- To UNSUBSCRIBE, email to debian-user-polish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f437e56.2000...@teneg.com.pl
VPN za maskaradą?
Witam, Nie mogę sobie poradzić z zagadnieniem jak w tytule. Z tego co wyczytałem w sieci istnieje faktycznie kłopot z przepuszczaniem ruchu VPN przez maskaradę. A jednak przecież multum sieci stoi za maskaradą i tyle samo multum ludzi korzysta z vpnu bedac w takiej konfiguracji. A konfiguracja jest najprostrza. 1. Router VPN centrala (sprzęt, nie 2. Siec Internet 3. Router z maskaradą Debian 4. Sieć lokalna z klientami wdzwanianymi pod Windows. Problem polega na tym, że wdzwaniany vpn klient z windows nie potrafi przejść choćby autoryzacji (lohgin/hasło), połączenie nie zestawia się. Ten sam klient przepięty na numery IP publiczne które omijają maskowanie wdzwania się bez problemu. Z tego co udało mi się znaleźć na sieci wynika, że maskarada w jakiś sposób modyfikuje pakiety vpnu przez co występują kłopoty ze spieciem takiego tunelu. Jest sporo opisów rozwiązań w oparciu o Swany ale sa to rozwiązania punkt punkt (w obu lokalizacjach są stawiane vpny na linuxie i nie przechodzą przez maskaradę). Znalazłem na necie wpisy do maskarady które przepuszaczały by poza maskaradą ruch na poszczególnych portach wykorzystywanych przy VPN: iptables --append INPUT --protocol AH --in-interface eth0 --jump ACCEPT iptables --append INPUT --protocol ESP --in-interface eth0 --jump ACCEPT iptables --append INPUT --protocol UDP --source-port 500 --destination-port 500 --in-interface eth0 --jump ACCEPT iptables --append INPUT --protocol UDP --source-port 4500 --destination-port 4500 --in-interface eth0 --jump ACCEPT tudzież próbowałem wykluczyć z maskarady protokoły odpowiedzialne za vpn: iptables -t nat -I POSTROUTING 1 -p 50 -j ACCEPT. iptables -t nat -I POSTROUTING 1 -p 51 -j ACCEPT. Bez skutku niestety :( Połączenia wdzwaniane przez klientów stojących za natem są przecież popularne. Ja nie mogę sobie dać z tym rady. Na każdym routerku za grosze jest opcja "VPN pass through". Ale jak to zrobić na Linuxie? Będę wdzięczny za każdą pomocną dłoń. Pozdrawiam, G.M. -- To UNSUBSCRIBE, email to debian-user-polish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/256BB14DC44C4B768FEDFCA028B6CC8A@MAIN2
