Re: VPN za maskaradą?

Dnia 2012-02-21, o godz. 12:06:22
"Sub" <[email protected]> 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