Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam
Staram się uruchomić vpn w "opcji" pptp postępując jak w przykładzie http://www.howtogeek.com/51237/setting-up-a-vpn-ppt … r-on-debian/. Problem polega na tym, że łącząc się wewnętrznie po lan połączenie zostaje nawiązane pozytywnie. Jednak jak chce połączyć sie z zewnątrz to zatrzymuje się na weryfikacji nazwy użytkownika i hasła i kończy błedem 619.
Klient---------Brama--------VPN
na bramie port 1723 oraz 47 sa przekierowane na vpn.
Jeżeli ktoś zna odpowiedź na problem pls help :)
Offline
Podejrzewam, że cała zabawa rozbija się o nat który lokalnie wykonywany nie jest, dlatego vpn się łączy.
Offline
na kompie z vpn widze połączenie na porcie 1723. nie wiem czy dobrze kombinuje ale jak wywale wpisy w /etc/ppp/chap-secrets (nazwa uzytkownika i haslo) to nawet nie pojawia się okno "trwa werfyfikacja nazwy..." tylko odrazu wywala bład z połączeniem.
Offline
proponuję użyć narzędzia tcpdump zamiast rm ;)
Warto też sprawdzić, czy urządzenie będące "bramą" ma wbudowaną obsługę GRE - jeśli pamięć mnie nie myli może być potrzebna. Choć czy na etapie autoryzacji jest potrzebna? - chyba nie.
Raczej używam OpenVPN, pptp to stawiałem 5 lat temu.
Ostatnio edytowany przez bobycob (2011-08-02 19:47:52)
Offline
bobycob napisał(-a):
proponuję użyć narzędzia tcpdump zamiast rm ;)
Warto też sprawdzić, czy urządzenie będące "bramą" ma wbudowaną obsługę GRE - jeśli pamięć mnie nie myli może być potrzebna. Choć czy na etapie autoryzacji jest potrzebna? - chyba nie.
Raczej używam OpenVPN, pptp to stawiałem 5 lat temu.
Obsługa GRE jak najbardziej będzie potrzebna , toż to tunel i po to jest otwierany port 47, bobycob nie myli Ciebie pamięć :)
Druga sprawa, że problem występuje dlatego że pptp nie jest "natowalny", ponieważ nawiązuje tylko jedna sesje kontrolna i jak jest następna to poprzednia jest zrywana i zastępowana tą następną ( do znalezienia w RFC 2637 ). Jakieś rzźby trzeba robić na bramie.
W jądrze powinno zapewne być załadowane:
CONFIG_NF_NAT_PROTO_GRE CONFIG_NF_NAT_PPTP CONFIG_NF_CONNTRACK_PPTP CONFIG_NF_CT_PROTO_GRE
a czy coś jeszcze to w sumie nie wiem.
I znów popieram kolegę bobycob , który proponuje Openvpn i zrobić tunel bezpieczny i szyfrowany tak jak to powinno być, bo pptp nic z tych rzeczy nie daje.
Ostatnio edytowany przez ba10 (2011-08-02 20:05:03)
Offline
Albo na żywca porty przekierować (wszystkie używane przez pptp), ewentualnie wszystko z adresu IP A kierować na routerze na host B za natem.
Iptables powinien dać radę.
Czyli coś w stylu:
iptables -t nat -I PREROUTING -s 88.212.54.78 -j DNAT --to-destination 192.168.56.1 iptables -t nat -I POSTROUTING -s 192.168.56.1 -d 88.212.54.78 -j SNAT --to-source <IP-routera>
gdzie 192.168.56.1 - host B, 88.212.54.78 -host A w internecie.
Ewentualnie coś z modułów dodatkowych RAWDNAT i RAWSNAT (oba działają w tablicy RAW netfiltera)
RAWDNAT target options: --to-destination addr[/mask] Address or network to map to
RAWSNAT target options: --to-source addr[/mask] Address or network to map to
Są w xtables-addons.
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2011-08-02 21:24:58)
Offline
Problem rozwiazany
Wystarczy załadować moduły :
ip_nat_pptp
ip_conntrack_pptp
Pozdrawiam
Offline