Wiem, że może protokół PPTP (Point to Point Tunneling Protocol) nie jest najbezpieczniejszy (sam na potrzeby „zawodowe” raczej używam choćby OpenVPN), ale przy zastosowaniu dobrego (odpowiednio długiego) hasła do użytku domowego nadaje się idealnie…
Spis treści w artykule
PPTP(D)
Za zastosowaniem tego protokołu do postawienia na Raspberry Pi serwera VPN przemawia też m.in.:
- Szybka i prostota konfiguracja po stronie serwera
- Natywna obsługa (jako klient) na dużej liczbie urządzeń (w tym np. telefony z systemem Android)
Instalacja
Zaczynamy od instalacji:
sudo apt-get install pptpd -y
W nowej wersji systemu (Raspbian/Raspberry Pi) może się zdarzyć, że podczas próby połączenia do serwera VPN pojawi się błąd, a w logu systemowym (var\log\syslog) znajdziemy np. takie błędy:
Couldn't open the /dev/ppp device: No such device or address
Please load the ppp_generic kernel module.
W takiej sytuacji należy zainstalować dodatkowo:
sudo apt-get install pptp-linux network-manager-pptp
Konfiguracja
Po instalacji czeka nas konfiguracja – tym razem nie skończy się na edycji jednego pliku i restarcie usługi, choć też dużo bardziej skomplikowane to nie będzie.
pptpd.conf
Na początek:
sudo nano /etc/pptpd.conf
I na samym końcu pliku szukamy linijek:
#localip 192.168.0.1
#remoteip 192.168.1.234-238,192.168.1.245
Usuwamy komentarz (kasujemy # znajdujący się na początku):
localip 192.168.0.1
remoteip 192.168.1.234-238,192.168.1.245
I szybkie wyjaśnienie:
- localip – podajcie lokalny (w sieci LAN) adres IP Raspberry Pi
- remoteip – zakres IP (lokalne IP w Waszej sieci LAN) które będą przydzielane dla klientów VPN
Np.:
localip 192.168.0.5
remoteip 192.168.0.101-120
- IP Raspberry Pi: 192.168.0.5
- Lokalne IP dla klientów VPN: od 192.168.0.101 do 192.168.0.120
- IP routera: 192.168.0.1 (maska 255.255.255.0)
pptpd-options
Edytujemy kolejny plik:
sudo nano /etc/ppp/pptpd-options
Również na końcu pliku dopisujemy:
ms-dns 192.168.0.1
nobsdcomp
noipx
mtu 1490
mru 1490
Gdzie „192.168.0.1” to adres IP naszego routera.
chap-secrets
W kolejnym pliku ustawimy nazwę użytkownika i hasło do połączenia:
sudo nano /etc/ppp/chap-secrets
Na końcu pliku dodajemy linijkę wg wzoru:
nazwa_użytkownika[TAB lub spacja]*[TAB lub spacja]hasło[TAB lub spacja]*
Czyli np.:
patryk * jakieś_hasło_do_połączenia *
Stały IP klienta/użytkownika
W tym pliku (chap-secrets) możesz również ustawić stały adres IP dla wybranego użytkownika, wystarczy w tym celu w czwartej kolumnie wpisać adres:
nazwa_użytkownika[TAB lub spacja]*[TAB lub spacja]hasło[TAB lub spacja]Adres_IP
Czyli np.:
patryk * jakieś_hasło_do_połączenia 192.168.0.111
sysctl.conf
Ostatni plik który zmodyfikujemy to:
sudo nano /etc/sysctl.conf
Dokonamy małej modyfikacji, dzięki czemu będziemy mieli dostęp z zewnątrz do zasobów w sieci lokalnej (LAN).
Szukamy linijki:
#net.ipv4.ip_forward=1
i usuwamy komentarz/zmieniamy na:
net.ipv4.ip_forward=1
Reguły firewalla
Warto od razu dodać jeszcze reguły firewalla, by w pełni móc korzystać z dobrodziejstw naszego VPSa:
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
sudo iptables -I INPUT -s 192.168.0.0/8 -i ppp0 -j ACCEPT
Oczywiście, jeśli mamy jakiś niestandardowy firewall, to w nim przeprowadzamy konfigurację…
Uruchamiamy serwer VPN
Korzystamy w tym celu z 2 komend:
sudo sysctl -p
sudo /etc/init.d/pptpd restart
W tym momencie nasz serwer VPN powinien już działać według wprowadzonych ustawiań…
W jednym z komentarzy pojawiło się pytanie jak ustawić automatyczny serwera – jeśli z jakichś przyczyn serwer PPTP/VPN nie startuje automatycznie (np. w Debian 8 Jessie) możecie to skorygować za pomocą poleceń:
sudo systemctl start pptpd
sudo systemctl enable pptpd
Pierwsze polecenie uruchomi serwer w danej sesji, drugie aktywuje/włączy automatyczny start.
Po restarcie systemu serwer powinien działać prawidłowo, co można sprawdzić np. poleceniem:
sudo systemctl status pptpd
Router
Z racji tego, że VPN z założenia skonfigurowaliśmy po to, by połączyć się zdalnie (z Internetu) z naszą siecią LAN nie obejdzie się bez jeszcze (minimum) jednej zmiany na routerze.
Musicie ustawić przekierowanie portu „z zewnątrz” do Raspberry Pi.
Po informacje jak to zrobić – odsyłam Was do instrukcji obsługi Waszego routera.
Klient VPN
Jeśli chodzi o konfigurację klienta VPN, to już wiele zależy od tego z jakiego urządzenia będziecie korzystali.
Ja pokaże na przykładzie 2 urządzeń które akurat teraz mam „pod ręką”:
Windows 7
W „Panelu sterowania” wybieramy „Centrum sieci i udostępniania”:
Następnie:
Skonfiguruj nowe połączenie lub nową sieć
Skonfiguruj połączenie bezprzewodowe, szerokopasmowe, telefoniczne, ad hoc lub VPN albo skonfiguruj router lub punkt dostępu.
Dalej:
Połącz z miejscem pracy
Skonfiguruj połączenie telefoniczne lub połączenie VPN z miejscem pracy.
Czy chcesz użyć połączenia, które już masz?
Wybieramy:
Nie, utwórz nowe połączenie
Dalej:
Użyj mojego połączenia internetowego (VPN)
Połącz przy użyciu połączenia wirtualnej sieci prywatnej (VPN) za pośrednictwem Internetu.
W następnym oknie musimy uzupełnić w pola:
- Adres internetowy – wpisujemy publiczny IP
- Nazwa miejsca docelowego – nazwa dla połączenia (np. „Testowe z Raspberry Pi”)
I tu mała uwaga:
By móc połączyć się z naszym routerem musimy mieć publiczny adres IP, najlepiej też stały.
O ile brak stałego adresu IP da się obejść (zobacz: Cloudflare DDNS), to w przypadku gdy nie mamy publicznego adresu IP – jesteśmy schowani za routerem dostawcy Internetu – tu raczej nic nie poradzimy, chyba, że dostawca Internetu jest w stanie zmienić nam adres na publiczny (najlepiej też stały), lub chociaż przekierować bezpośrednio do nas ruch na konkretnym porcie.
Klikamy „Dalej”, i podajemy nazwę użytkownika i hasło:
- Nazwa użytkownika: patryk (zmień na własną :-))
- Hasło: wiadomo…
Można zaznaczyć „Zapamiętaj to hasło”, następnie klikamy „połącz”.
Jeśli wszystko ustawiliśmy poprawnie po chwili powinniśmy uzyskać połączenie:
Utworzone połączenie powinno też pojawić się na liście naszych połączeń sieciowych:
Android
W przypadku telefonu z system Android jest chyba jeszcze prościej, wystarczy wybrać kolejno:
- Ustawienia
- Sieci zwykłe i bezprzewodowe
- Ustawienia sieci VPN
- Dodaj sieć VPN
- Dodaj sieć VPN PPTP
I uzupełnić dwa elementy:
- Nazwa sieci VPN – nazwa pod jaką będziemy widzieli połączenie
- Ustaw serwer sieci VPN – wpisz swój publiczny adres IP
Na liście sieci VPN pojawiła się nowa sieć, wystarczy teraz na niej kliknąć, podać nazwę użytkownika i hasło:
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
Witam. Fantastyczny blog, zwłąszcza sekcja Raspberry Pi. Chciałbym zachęcić do napisania tekstu o pakiecie n2n, umożliwiającym bezpośrednie łączenie się dwóch maszyn zza nat, bez stałego ip i dostępu do bramy (w ramach usługi udostępniony darmowy serwer pośredniczący, jak w gg, skype czy innych).
Polecam (choćwciąż szukam takiego rozwiązania, króte pozwoli mi się łączyć z Raspberry z telefonu na Androidzie).
http://eko.one.pl/?p=openwrt-n2n
http://www.ntop.org/products/n2n/
http://www.elektroda.pl/rtvforum/viewtopic.php?p=11997286
Osobiście nie mam szans na łącze ze stałym IP, nie mam dostępu do bramy, a chciałbym mieć możliwość zalogowania się do Raspberry po ssh z dowolnego miejsca, najlepiej z telefonu na Androidzie.
Witam
Kiedyś już chyba słyszałem o tym n2n – kolega ma ten sam „problem” z brakiem publicznego IP – choć przyznam się, że nie zgłębiałem się zbytnio w ten temat – brak potrzeby… Może trzeba będzie to nadrobić :-)
Co do sekcji o Raspberry Pi – chwilowo troszkę musiałem zwolnić, bo wszystkie moje Pi mają tymczasowo przydzielone inne zadania…
Ale mam nadzieję, że to kwestia najbliższych dni, zwłaszcza że jest już przygotowanych kilka następnych poradników, zostało je „ładnie ubrać”… I stopniowo będę przechodził w nich z czystego software bardziej w kierunku hardware (m.in. GPIO).
Wprawdzie to nie to samo co SSH, ale może zainteresuje Cię, że kolega od „braku publicznego IP” testuje sterowanie Pi – w tym obsługę shella i GPIO (odczyt/zapis stanów, skrypty) z poziomu Google Talka, który jest w Androidzie jak najbardziej dostępny i nie wymaga do działania publicznego IP.
I jak na razie wszystko jest OK
Znalazłem jeszcze to:
http://progrium.com/localtunnel/
Zapowiada się rewelacyjnie, ale jeszcze nie sprawdzałem.
Na szybko ciężko coś więcej o tym powiedzieć, bo na stronie na temat serwisu/usługi informacji chyba niewiele… Internet trochę rozjaśnia sytuację…
Ale szybki test na Pi (jedna ze sztuk testowych/dev) i przy uruchamianiu jest błąd – jak podpowiada Google – dość powszechny…
Google może podpowiadać… moje wpisy (pytałem już w wielu miejscach. Ale zobacz na to:
„Testowałem na zwykłym Debian lenny (płytka Alix 2c0) i działa prawidłowo dla popularnych portów (80/22). Na RP masz jakąś standardowa dystrybucje czy specjalnie przygotowaną ?”
http://www.elektroda.pl/rtvforum/viewtopic.php?p=12042797#12042797
Test (szybki i zdalny) konkretnie na sztuce kolegi, a tam Raspbian – ale, że to żadne z moich Pi to ciężko mi powiedzieć co konkretnie tam siedzi… W każdym razie błąd – niezależnie od portu… Ale zobaczymy może wieczorem jeszcze, znajomy ma doinstalować „na wszelki wypadek” jeszcze jeden pakiecik…
Może niebawem uda mi się zrobić test u siebie, choć…
Zgłosiłem jako bug Raspbiana (skoro na Debianie działa poprawnie…)
https://bugs.launchpad.net/raspbian/+bug/1153539
Może faktycznie to jest to…
Choć jak patrze na zgłoszenie, to coś mi się wydaje, że u kolegi błąd był inny… Ale będę mógł to zweryfikować najwcześniej wieczorem…
Rozwiązanie:
https://groups.google.com/forum/?hl=pl&fromgroups=#!topic/localtunnel/jnG890XAEOs
Połączenia po ssh będą możliwe za jakiś czas:
https://groups.google.com/forum/#!topic/localtunnel/_bbN_Y5c39I
Jeśli ktoś zna inne działające rozwiązanie (poza płatnym pagekite), proszę niech się podzieli.
PageKite jest za darmo (Open Source), tylko w tym wypadku samodzielnie trzeba się zatroszczyć o „serwer” (ale tu wystarczy praktcznie dowolny komputer z publicznym IP).
PS. Trzymam kciuki za RaSp485berry, i czekam na dalsze informacje o projekcie – zwłaszcza, ze znajomymi też wykorzystujemy (m.in.) Pi jako część układu zarządzania i kontroli mieszkań… Choć bardziej „amatorsko”, czyli nie pod projekt komercyjny/publiczny ;-)
Fajny poradnik.. Tylko problem co znajdę poradnik na temat VPN PPtp to mi nie działa
Wszystko robię w/g schematu.. Router dostaję domenę z dyndns.org ,raspberry zostaję dodana do DMZ
na androidzie w telefonie próbuje utworzyć połączenie i NIc ….
Czy to może być wina neostrady?
A czy w ramach sieci lokalnej (LAN) jest możliwość połączenia się w ramach sieci VPN? I ew. kolejny test to czy z jakiegoś komputera jest taka możliwość…
Może w trakcie tych wcześniejszych „prób” coś tam w systemie teraz nie tak, i może warto zacząć od wyczyszczenia (odinstalować składniki z parametrem „purge”)
Jeśli pytasz czy próbowałem to nie, natomiast serwer www odpowiada przez dyndns
Może faktycznie spróbuję zainstalować system od nowa i jeszcze raz przyłożę się do instrukcji.
To sugerowałbym zacząć od testu, czy lokalnie (LAN) da się połączyć, bo niemożna wykluczyć, że akurat „coś gdzieś” jest zablokowane…
Sprawdź też, czy router obsługuje tego typu/rodzaju ruchu między LAN a WAN (sieć lokalna/Internet). Poszukaj w routerze (funkcjach i/lub specyfikacji) np. czegoś w stylu „VPN Pass-Through”.
Co do instalowania systemu od nowa, to zacząłbym od czegoś mniej „radykalnego”, a mianowicie odinstalowania PPTPd wraz z ustawieniami:
I ponowna instalacja:
wpisuje w termianlu : ppp-compress-18
ppp-compress-18: command not found (jeśli niema błędu to ok) a u nie jest i co mam z tym zrobć ?
Mój błąd – uciekło podczas edycji, powinno być:
Ale w przypadku Raspbiana to raczej zbyteczny krok, tam wszystko co trzeba jest :-)
Patryk -u udało mi się uruchomić serwer vpn Na lanie jak i z neta ( koledzy sprawdzili połączenie ) połączyli się i otrzymali adres ..
teraz mam pytanie :
1.klient wpisując IP serwera vpn (zainstalowany apache2) nie wyświetla ich strony Przeglądarka
2. serwer pingując klienta otrzymuje odpowiedz natomiast w drugą stronę już tylko głuchy telefon..
3. Jeśli wyznaczyłem pulę od 130-140 ( 10 adresów) to czy będę mógł nawiązać połączenie np. z routerem który jest na x.x.x.150?
Marku :-)
Ad1: IP serwera VPN (Raspberry Pi) to rozumiem, że tylko w ramach sieci LAN. W innym wypadku („z internetu”) wpisujesz IP routera (publiczny) i tu przekierowanie portu do Pi.
Jeśli chodzi o WWW to dodatkowo na routerze musisz ustawić przekierowanie portów (80 i ew 443 dla https), choć nie wiem czy nie korzystasz z DMZ – bo chyba kiedyś o tym wspominałeś… Pamiętaj też, że w przypadku połączenia VPN jako adres serwera WWW wystarczy wpisać lokalny adres IP (LAN).
W przypadku problemów najlepiej sprawdzić lokalnie czy działa serwer/WWW (localhost/127.0.0.1), później LAN… A na końcu „z internetu” + ew VPN – pozwoli Ci to zlokalizować „słabe ogniwo”.
Ad2: Za mało danych (LAN, VPN, internet) – sprawdź może wg procedury z ostatniego zdanie Ad1. Jest też możliwość, że na serwerze blokujesz PING (np. jakiś firewall)
Sprawdź też, czy w konfiguracji serwera VPN „nie przegapiłeś” np. odkomentowania „net.ipv4.ip_forward=1” – dość powszechny problem/błąd ;-)
Ad3: Wyznaczona pula (130-140 – 11 adresów by być precyzyjnym :-)) rozumie, że dotyczy klientów VPN? W tym wypadku oni będą dostawać adresy z tej puli… A dalej to już wygląda jak w przypadku sieci LAN, do której to VPN otwiera im dostęp.
Więc tak – klient z IP *.*.*.130 będzie mógł połączyć się z *.*.*.150
Oczywiście o ile nie ustawiłeś dodatkowych ograniczeń (VPN, router itp.)
Patryku , dzisiaj sprawdzałem połączenie na tablecie z androidem ( android z internetem mobilnym )
Jechałem do Wrocławia i miałem dostęp do wszystkich urządzeń od strony www (routery ,drukarki, accesPointy)..Zastanawia mnie fakt iż na windowsie XP na kompie mojej dziewczyny ( u niej w domu) połączenie zostało utworzone ale brak dostępu z żadnymi urządzeniami od strony WWW ..
Jaki może być problem ? (co mi z połączenia jak nie mam dostępu do routerów i drukarek)
Jak wcześniej wspominałem raspberry ma ustawione DMZ na routerze głównym
Pozdrawiam
Nie napisałeś, czy komputer dziewczyny łączy się z internetem „bezpośrednio”, czy (teraz chyba najczęściej spotykane) przez router/sieć LAN.
Z tego co mi na szybko przychodzi do głowy, to sprawdź czy komputer otrzymuje prawidłowe IP (IP, brama, maska), i czy nie ma konfliktu między LAN a VPN (m.in. chodzi o zbieżną adresację).
Zobacz:
Ps. Antywirus/firewall po stronie XP to pewnie sprawdzone, że nic nie blokuje? :-)
Tak jak napisałeś Łączy się przez Router (TP)
Mam już rozwiązanie tego problemu , pochwale się z resztą społeczności tylko jak zrobię dokładną dokumentację co i jak …;-)
Ale twoje rady nakierunkowały mnie w dobrą stronę by rozwiązać ten problem ;-)
Jeszcze raz dzięki i wesołych świąt
ftp://ftp.draytek.pl/POMOC/Gotowe_przyklady/VPN_Dostep_zdalny/Host-LAN/Host-LAN_PPTP_WinXP.pdf
strona 10 wystarczy tak samo ustawić i będzie działać//
To tak dla kompletu, jakby PDF z jakiś przyczyn wyleciał:
Dotyczy to systemu Windows XP
Witam czy mógłbym prosić o pdf z dokumentacją?
Mały błąd w OutLink’u zmieniał ftp na http, już powinno być OK:
ftp://ftp.draytek.pl/POMOC/Gotowe_przyklady/VPN_Dostep_zdalny/Host-LAN/Host-LAN_PPTP_WinXP.pdf
Pisałem pytanie pod artykułem
https://webinsider.pl/raspberry-pi-serwer-multimediow-dlna/#comment-18480
o dostępie do serwera dlna z zewnątrz.
Czy taki vpn można do tego użyć? Coś mi się zdaje, że się nada, ale potrzeba mi wskazówek.
VPN daje (bezpieczny) dostęp do sieci LAN – a więc i lokalnych zasobów – z zewnątrz. Oczywiście można użyć VPNa, ale to jest tylko (lub aż) metoda dostępu do lokalnej sieci LAN. Sprawdzi się jeśli coś nam działa tylko lokalnie (sieć LAN), a chcemy mieć do tych zasobów dostęp z zewnątrz (internet).
Do słuchania muzyki „poza domem” dopisałem dziś poradnik dotyczący Music Player Daemon (mpd) m.in. w Raspberry Pi. Może to będzie to…
Witam,
zrobiłem wszystko dokładnie jak opisane w artykule natomiast w żaden sposób nie mogę się połączyć z VPN :( Oczywiście SFTP, SSH i HTTP z zewnątrz działa bez problemu tylko VPN nie :(
Jakieś pomysły? Dodam, że oczywiście zrobiłem przekierowanie portu na maline.
Akurat z 2 miesiące temu konfigurowałem u znajomego VPNa na Raspberry Pi wg tego poradnika (przy okazji go weryfikując) i wszystko było OK.
Zacząłbym od sprawdzenia w ustawieniach routera (i ew. instrukcji) czy nie trzeba dodatkowo aktywować w nim jakiejś opcji, by zaczął „przepuszczać” ruch VPN/PPTP.
Spróbuj też ew. połączyć się lokalnie, w ramach sieci LAN – jeśli to się uda, to raczej na pewno przyczyny problemu należy szukać gdzieś w łączniku LAN-WAN, czyli routerze.
Może coś Ci pomoże również aktywacja logowania dla usługi PPTP(D):
Znajdź tu linijkę:
i usuń z niej znak komentarza (#). Zapis, zrestartuj usługę VPN i spróbuj się połączyć… Nawet jak się nie uda, to być może odpowiedź (lub coś co Cię na nią naprowadzi) znajdziesz w pliku:
Jeśli będzie pusty – to też jakaś informacja, bo może wskazywać na to, że „próba połączenia” nie dociera do Pi/usługi PPTP(D).
Jak się uda na coś trafić to daj znać, może się jeszcze komuś przyda…
Dodam, że po wpisaniu „sudo service pptpd restart” nic sie nie pokazuje. Po wpisaniu komendy top widzę że jest pptpd.
Przy próbie połączenia po sieci lokalnej wpisuje adres serwera: 192.168.1.40 i wyskakuje info „A connection to the remote computer could not be estabilished, so the port used for this connection was closed.” :(
A w pliku /var/log/debug coś masz?
an 20 13:37:47 kuchar-pi PackageKit: daemon start
Jan 20 13:50:21 kuchar-pi pptpd[2000]: CTRL: Reaping child PPP[2001]
Jan 20 13:52:15 kuchar-pi pptpd[2024]: CTRL: Reaping child PPP[2025]
Jan 20 13:53:04 kuchar-pi pptpd[2036]: CTRL: Reaping child PPP[2037]
Jan 20 13:55:26 kuchar-pi pptpd[2050]: CTRL: Reaping child PPP[2051]
Jan 20 13:56:58 kuchar-pi pptpd[2080]: CTRL: Reaping child PPP[2081]
Jan 20 13:58:32 kuchar-pi pptpd[2093]: CTRL: Reaping child PPP[2094]
Jan 20 14:00:23 kuchar-pi pptpd[2107]: CTRL: Reaping child PPP[2108]
Jan 20 14:02:47 kuchar-pi pptpd[2140]: CTRL: Reaping child PPP[2141]
Jan 20 14:04:31 kuchar-pi kernel: [ 0.000000] On node 0 totalpages: 253952
Jan 20 14:04:31 kuchar-pi kernel: [ 0.000000] free_area_init_node: node 0, pgdat 8085cec0, node_mem_map bcb48000
Jan 20 14:04:31 kuchar-pi kernel: [ 0.000000] Normal zone: 2232 pages used for memmap
Jan 20 14:04:31 kuchar-pi kernel: [ 0.000000] Normal zone: 0 pages reserved
Jan 20 14:04:31 kuchar-pi kernel: [ 0.000000] Normal zone: 253952 pages, LIFO batch:31
Jan 20 14:04:31 kuchar-pi kernel: [ 0.000000] pcpu-alloc: s20416 r8192 d20544 u49152 alloc=12*4096
Jan 20 14:04:31 kuchar-pi kernel: [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Jan 20 14:04:31 kuchar-pi kernel: [ 1.630863] dwc_otg: Microframe scheduler enabled
Jan 20 14:04:31 kuchar-pi kernel: [ 1.736377] dwc_otg: FIQ enabled
Jan 20 14:04:31 kuchar-pi kernel: [ 1.736390] dwc_otg: NAK holdoff enabled
Jan 20 14:04:31 kuchar-pi kernel: [ 1.736400] dwc_otg: FIQ split-transaction FSM enabled
Jan 20 14:04:31 kuchar-pi kernel: [ 1.736438] Module dwc_common_port init
Jan 20 14:04:31 kuchar-pi kernel: [ 9.416553] sd 0:0:0:0: [sda] Mode Sense: 47 00 10 08
A zakomentuj w pliku /etc/pptpd.conf linijkę:
I standardowo – restart usługi i próba połączenia (lokalnego, po LANie)
Możesz też spróbować komendy:
Choć nie widzę tutaj błędu tego typu, ale może…
Musisz też mieć świadomość, że nie wszystkie „domowe routery” są w stanie prawidłowo udostępniać serwer VPN (chodzi m.in. o protokół GRE), wtedy można próbować ratować się np. usługą OpenVPN (chyba nie opisywałem, bo to troszkę trudniejsza sprawa, tj. więcej miejsc gdzie „u kogoś coś może pójść nie tak”).
A sprawdzałeś czy masz opcję „PPTP passthrough” w ustawieniach routera, i czy jest ona aktywna?
Zrobiłem jak piszesz i nic nie pomogło :( Na router mam opcje Okienko PPTP włączone.
Niewiem czy to ma jakiś wpływ na to ale jak wpisuje „sudo sysctl -p” to w odpowiedzi mam tylko:
kernel.printk = 3 4 1 3
net.ipv4.ip_forward = 1
Wynik z sysctl jest OK, zresztą w Twoim przypadku brak routingu nie jest problemem.
Nie wiem jaki masz router, ani z jakiego urządzenia próbujesz się połączyć z serwerem PPTP/VPN, ale może „wrzuć to w Google”, i coś się pojawi – może nie tylko Ty trafiłeś na taki problem…
Jak ustawić autostart serwera?
Z tego co kojarzę, to serwer PPTP/VPN po instalacji i konfiguracji startuje automatycznie.OK, faktycznie w Debian 8 Jessie (a przynajmniej w wersji Raspbian na Raspberry Pi) „może się zdarzyć”, że serwer PPTP/VPN nie będzie startował automatycznie, podczas startu systemu.
W takiej sytuacji wystarczy skorzystać z poleceń:
Po restarcie systemu serwer powinien działać prawidłowo, co można sprawdzić np. poleceniem:
Dzięki :D
Witam,
Mam zagwozdkę… tutorial świetny i serwerek działa u mnie jak marzenie :)
Mam w sieci różne systemy operacyjne i chce użyć malinki jako „punktu zbiorczego”, w sensie foldery udostępnione przez windowsy zamontować na malince i potem udostępnić je dalej do Mac OSa. Tutaj przydał się cifs i działa to super. Tylko mam problem bo komp z windowsem podpinając się do malinki dostaje różne IP z puli. Da się ustawić statyczne IP dla poszczególnym komputerów?
Tak, można to zrobić „na sztywno” w właściwościach połączenia na każdym komputerze, lub – zalecam – skorzystać z serwera DHCP, który wbudowany jest chyba w każdy router (poszukaj w ustawieniach routera, zazwyczaj jest to dość eksponowana opcja).
Hmmm… Router mi to załatwi. Komp o którym mowię łączy sie z zewnątrz. IP nadaje mu VPN. No ale spróbuje.
Ale te wszystkie urządzenia są w jednej sieci LAN? Czy rozproszone, i łączą się przez internet, po VPNie?
W pierwszym przypadku ustawienia DHCP na routerze, w drugim – lokalny adres IP dla klienta/użytkownika PPTP/VPN ustawisz w pliku „chap-secrets”, czyli tam gdzie ustawisz nazwę użytkownika i hasło (zaktualizowałem wpis, tak by ta informacja była bardziej wyeksponowana).
Łączą sie przez VPN. Sprawdzę to jak bede miał dostęp do konsoli i sprawdzę, dzięki za pomoc :)
Sprawdziłem i działa. W sumie zrobiłem tak zanim napisałem tutaj posta. Ale ustawiłem zły MAC Adres (czeski błąd w przepisywaniu) i dlatego mi nie działało :) Dzięki jeszcze raz za pomoc :)
Fajnie, że już działa, ale – pisze to z pamięci, więc mogę się mylić – tam chyba nigdzie nie podajmy adresu MAC, bo przypisywanie adresów IP w ramach PPTP odbywa się po nazwie użytkownika (chyba, że mowa o DHCP w routerze).
O ustawieniach na ruterze mowie. Niestety ja używam jednej nazwy użytkownika do paru komputerów, więc u mnie przypisanie IP do Loginu nie rozwiązuje problemu.
Router (DHCP) chyba w tym przypadku (VPN@Pi) nie pomoże.
I zdecydowanie lepiej korzystać z różnych użytkowników VPN dla poszczególnych urządzeń – chwila konfiguracji więcej, a poza możliwością przypisania IP bezpieczniej, bo w przypadku „nieplanowanej utraty” jednego urządzenia, nie trzeba zmieniać haseł do VPNa na pozostałych, a wystarczy wyłączyć tego użytkownika.
U mnie wygląda w ten sposób że malina jest w tej samej podsieci co router. Udało mi się nawiązać połączenie ale nie działa internet po podłączeniu przez vpn(tak jakby gateway nie był ustawiony), dodam że mam połączenie tylko z malina (tylko ona odpowiada na pingi). W jaki sposób to rozwiązać? pozdrawiam
Wszystko – a przynajmniej mam taką nadzieję, zwłaszcza że niedawno testowałem ten poradnik – masz opisane w poradniku, po prostu sprawdź czy wykonałeś wszystkie kroki, i raczej powinno działać.
Ale by jakoś Cię dodatkowo naprowadzić, to zacząłbym od sprawdzenia ustawień w pliku „sysctl.conf”, np. za pomocą polecenia:
W odpowiedzi powinieneś otrzymać coś takiego:
Sprawdź też status usługi, i w razie błędów najlepiej zrestartuj (dla pewności, bo czasem restart samej usługi to za mało) Pi:
Możesz też sprawdzić parametry (IP, brama) jakie otrzymujesz po połączeniu, i ew. sprawdzić ścieżkę do jakiejś strony – raczej po IP (np. DNSy Google: 8.8.8.8).
Jeśli korzystasz z jakiegoś firewalla to pamiętaj by jego konfigurację również uwzględnić przy konfiguracji VPNa (opisywałem to na przykładzie UFW – Uncomplicated Firewall).
Również pozdrawiam, i powodzenia – i jak znajdziesz rozwiązanie, to prosiłbym byś dał znać w komentarzu, bo może jeszcze komuś się przyda…
Częściowo udało mi się to naprawić, na moje potrzeby to wystarczy :) trzeba po prostu ustawić adresy na karcie vpn ręcznie w windowsie jest do tego komenda która w moim przypadku wygląda tak:
Netsh Interface IP Set Address „hauz” static 192.168.1.54 255.255.255.0 192.168.1.1
gdzie „hauz” to nazwa połączenia vpn, 192.168.1.54 to adres jaki otrzymamy po podłączeniu się, 255.255.255.0 to maska podsieci, a 192.168.1.1 to gateway
maska niestety po połączeniu zmienia się na 255.255.255.255 przez co mamy dostęp tylko do bramy i do maliny. Może da się to jakoś zdefiniować w pliku /etc/ppp/chap-secrets na malinie?
A i ważna sprawa aby w pliku /etc/ppp/chap-secrets ustawic ten sam adres ip co na w połączeniu vpn
W „chap-secrets” możesz ew. tylko ustawić IP jakie zostanie przypisane do danego użytkownika.
Adresy (IP, brama, maska) dla połączenia VPN w Windowsie ustawisz „na sztywno” również – tak jak i dla każdego innego – w panelu sterowania (Sieć i internet > połączenia sieciowe), tylko, że jak skonfigurujesz serwer VPN na Pi – tak jak w poradniku – to nie będzie takiej potrzeby, bo wszystkie parametry będą przekazywane podczas połączenia (specjalnie przed chwilą skonfigurowałem testowe połączenie VPN do Pi).
Zobacz, czy w pliku „/etc/pptpd.conf” dobrze ustawiłeś „remoteip” – jest to pula z której są przydzielane IP dla klientów VPN.
Dobrze ustawiłem :) tak jak pisałem wcześniej, w poradniku jest:
192.168.0.1 ip routera
192.168.1.1 ip maliny
(chyba że się mylę)
a u mnie jest:
192.168.1.1 router
192.168.1.15 malina
pewnie tu jest rozbieżność ale nie ważne i tak działa :) w wolnej chwili to jeszcze przeanalizuje :)
niemniej jednak bardzo dziękuje za poradnik i odpowiedzi, pozdrawiam serdecznie
Ale przy takiej konfiguracji ustaw maskę na routerze na 255.255.0.0 (zaraz doprecyzuje we wpisie), albo zmień IP Raspberry Pi i przydzielane przez VPN na 192.168.0.* (jeśli IP routera to 192.168.0.1, i maska 255.255.255.0 w Twojej sieci LAN).
A wiesz może czy dlna będzie działać po podłączeniu się przez vpn?
Hm… to mi zagwozdkę dałeś… ;-)
Nigdy chyba nie testowałem, choć nie wiem, czy nie będziesz musiał zainteresować się OpenVPN zamiast PPTP, ale musisz sprawdzić (i daj znać, sam jestem ciekaw).
Niestety serwer dlna jest niewidoczny po podłączeniu się przez vpn. Ale rozwiązałem to w ten sposób że zainstalowałem apacha przekierowałem jego documentroot na kartę pamięci i jak coś chcę przez pc włączyć to kopiuje ścieżkę do vlc i działa bez problemów natomiast z telefonu to klikam na plik i wybieram aplikacje którą chcę otworzyć . Ogólnie działa to bardzo sprawnie mogę nawet filmy oglądać które ważą powiedzmy giga i trwają 2h. Dużą zaletą jest to że również napisy w formacie srt są wyświetlane :) pozdrawiam
A może Samba/SMB? Ew. możesz poszukać, czy przy OpenVPN nie da się jakoś DLNA odpalić…
Odpaliłem serwer, ale mam problem, na raz podłączony może być tylko jeden klient, a połączenie z androida i połączenie ponownie nie działa muszę restartować Pi. Klienci w chap-secrets mają wpisane adresy na stałe. Co może być przyczyną?
Przed chwilą przetestowałem jednoczesne połączenie 2 klientów (telefon i komputer) do serwera (Raspberry Pi model B) i wszystko działa, dostęp do sieci i internetu jest, choć nie korzystam z IP ustawianych „na sztywno” (chap-secrets), ale też nie wydaje mi się, by to mogło być przyczyną – ale ze względu na łatwość tego testu, na Twoim miejscu bym go wykonał.
Sprawdź też log(i), może tam znajdziesz coś, co Cię naprowadzi na rozwiązanie problemu…
Jak masz możliwość, to zaloguj się do konsoli na Pi, i obserwuj zużycie pamięci (RAM) i obciążenie procesora (CPU) podczas połączenia, choć w przypadku problemów z wydajnością objawy powinny być inne.
Nie wiem, czemu ale ten problem występuje tylko w momencie kiedy chcę więcej niż jedno urządzenie podłączyć z mojej domowej sieci, jeżeli łączę się z różnych sieci to wszystko działa. Warto w opisie dodać, że można na urządzeniach z windowsem wyłączyć w połączeniu VPN jako główną bramę wtedy tylko konieczny ruch sieciowy idzie przez VPN, reszta już nie.
Tak, ale zawsze zostaje problem co jest koniecznych ruchem sieciowym. Ja z założenia przez VPN przepuszczam cały ruch, choć zazwyczaj nie ściągam wtedy gigabajtów…. ;-)
Cześć.
Wczoraj, pochłonięty wręcz nudą, pomyślałem sobie – hej, czemu by nie postawić VPN’a na Pi Zero? To jest myśl!
Chwila googlowania i trafiłem tutaj. Ok, robię po kolei wszystko, co zostało opisane. Instalacja, konfiguracja, puszczanie odpowiednich portów i protokołu GRE w ruterze. Czas na ostateczne testy!
No i tu zaczyna się problem.
Połączenie z moją siecią nawiązuję bez przeszkód, po Internetach mogę śmigać, na ruter mogę się dostać, wszystko miodzio. Problem jest jednak mocno znaczący – co chwila moje połączenie z VPN zostaje zerwane, bez jakiejś specjalnej przyczyny chyba. Testowałem i na tablecie z Windowsem 8.1 i na smarkfonie z Windowsem 10m i ciągle jest tak samo. Próbując szukać przyczyny zdołałem tylko wynaleźć w zdarzeniach systemu Windows komunikat o id 20226, kod błędu 829. Zacząłem szperać po necie, jednak nie znalazłem nic, co mogłoby mi pomóc. Pomyślałem sobie, że może ktoś miał podobny problem tu, w komentarzach. Niestety nie miał, ale znalazłem poradę autora wpisu co do opcji debug w konfigu. Pełen skowronków, że może tym razem się dowiem o co chodzi, odhaszowuję tę opcję, łączę się telefonem i sprawdzam czy jest coś ciekawego w debugu. Coś tam jest. Głównie wpisy typu „Apr 8 14:04:00 pi-zero pptpd[1132]: GRE: accepting packet #335” sugerujące raczej poprawne działanie serwera, jednak poniżej, chyba już po rozłączeniu, jest coś takiego:
„Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: Reaping child PPP[1133]
Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: Exiting with active call
Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: Made a CALL DISCONNECT RPLY packet
Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: I wrote 148 bytes to the client.
Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: Sent packet to client
Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: Made a STOP CTRL REQ packet
Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: I wrote 16 bytes to the client.
Apr 8 14:04:49 pi-zero pptpd[1132]: CTRL: Sent packet to client
Apr 8 14:04:54 pi-zero pptpd[1132]: CTRL: Exiting now
Apr 8 14:04:54 pi-zero pptpd[1108]: MGR: Reaped child 1132”
i nic poza tym.
Moim ruterem jest jakże wspaniały, olśniewający Netia Spot, którego często mam serdecznie dosyć. ;)
Malinka podłączona jest do rutera za pomocą połączenia WiFi dynksem na USB. Może tu jest pies pogrzebany? Chociaż, ja wiem… WiFi lubi być niestabilnym przy zastosowaniach serwerowych, ale malinka jest z 3 cm od rutera. ;)
W akcie desperacji zacząłem się zastanawiać, czy winowajcą nie jest stosunkowo słaby zasilacz Jabra 600mA i czy przypadkiem przy delikatnie wyższym obciążeniu nie odcina mi zasilania od adaptera, ale nie – połączenie SSH działa cały czas bez problemu.
Co może być nie tak?
Ach, zapomniałem zupełnie.
Systemem operacyjnym na tej malince jest minibian, z racji bardzo małej karty SD (całe 2GB). ;)
Minibiana nigdy nie używałem, ale poza „redukcją wagi” nadal jest to Debian (trochę przypadek, ale ciesze się, że Raspbiana oparto na Debianie, bo akurat jest to jedyny Linux z którym pracuje (pomijam dystrybucje narzędziowe), a więc łatwiej było mi zacząć korzystać z Pi… :-)
Tak naprawdę ciężko chyba jednoznacznie wskazać problem, ale zacząłbym – skoro poruszyłeś ten temat – od zasilacza, nawet na chwile podłącz ładowarkę od telefonu (choć dla Pi Zero 600 mA wydaje się aż nadto, no ale jest jest karta WiFi na USB). Sprawdziłbym też (np. komendą PING + np. obciążenie CPU) czy nie zdarza się zanik internetu – może spróbuj podłączyć kartę WiFi przez aktywnego HUBa… Właściwie wszystko sprowadza się do testów, testów, i jeszcze raz testów, oraz eliminacji kolejnych „przyczyn”.
Niestety, ale nie bardzo wiem co innego Ci poradzić…
Każdy chyba zaczynał swoją przygodę z Linuksem na distro opartym o Debianie/na samym Debianie. Nie inaczej było ze mną ;) Debiana jak i inne debianopochodne dystrybucje darzę sporą sympatią, choć na lapku mam postawionego Archa. Po prostu najbardziej jestem do nich przyzwyczajony, choć Arch też jest fajny :P
No nic, w takim razie będę jeszcze jakoś testować. Spróbuję to, czego nie próbowałem do tej pory, czyli właśnie zamienić zasilacz chociażby. Sprawdzę też jak to wszystko będzie wyglądać na Pi 2, którą mam podłączoną już kablem. Gdyby się okazało, że wszystko jest ok, to spróbuję tego samego dokonać z WiFi.
Jeżeli uda mi się cokolwiek ustalić, dam znać. Tymczasem dzięki za odpowiedź. ;)
Jeszcze z 5 lat temu ja byłem „sysadmin Windows i domena (Active Directory)”, a od Linuxa był inny dział – ale wiele się zmieniło od tego czasu, i w tej chwili więcej „admin” na Linuxie niż Windowsie, choć nie wydaje mi się bym był w stanie zrezygnować z Windowsa jako głównego systemu (przynajmniej na razie). Zwłaszcza, że teraz Bash/Ubuntu zawitał do Windowsa… :-)
Z Pi 2 może być dobry test, bo tam masz kabel, a więc odpadają ew. problemy z WiFi – sprawę ułatwia też to, że w większości przypadków kartę z systemem (przynajmniej Raspbianem) można swobodnie przenosić między Pi w różnych wersjach.
Powodzenia, i jakbyś na coś trafił to daj znać, będzie dla innych… :-)
Cóż, przeprowadziłem różnorakie testy. Zmieniłem zasilacz na 2A. Potem wsadziłem tą kartę do Pi 2 i zarówno z kablem jak i WiFi było to samo. Pomyślałem sobie, że czemu by nie sprawdzić na Raspbianie, który jest na karcie Pi 2?
Spróbowałem. Póki co jedynie kablem, ale myślę, że z WiFi rezultat będzie identyczny – działa w porządku, nic nie przerywa ani nie rozłącza.
Wniosek jest jeden – coś jest nie tak z minibianem. ;)
Jutro spróbuję jeszcze doinstalować iptables (choć nie sądzę, by to pomogło) i spróbuję może z jakimś innym distro. Widziałem coś takiego jak Raspbian Lite – może to się nada? Zobaczymy. ;)
Tymczasem miałbym jeszcze jedno pytanie – czy ktoś zetknął się z problemem połączenia VPN za pomocą mobilnej sieci Orange? Przy próbie połączenia z VPN’em (właściwie to z domowym FTP też) zachowuje się, jakby operator zablokowane miał niezbędne porty. Po prostu zawisa na „trwa łączenie…”, po czym wypluwa komunikat, że „nydyrydy” się połączyć z serwerem. Czy ktokolwiek się z tym spotkał i czy można temu zaradzić?
Kiedyś krążyły „tu i ówdzie” różne informacje, o różnych blokadach… Ale zapytałem teraz kolegę, który powiedzmy, że „raczej ma aktualne informacje z pierwszej ręki”, i mówi, że powinno działać – oczywiście urządzenie z mobilnym internetem jest klientem, a nie serwerem (standardowo „mobilnie” jesteś za NATem).
Zresztą kilka lat temu jak miałem jeszcze tel w Orange, to wydaje mi się, że nie miałem z tym problemów.
A ten sam telefon, w tej samej konfiguracji gdy jesteś połączony z internetem po WiFi łączy się? Pisząc „połączony do WiFi” mam na myśli inną sieć niż ta w której znajduje się serwer VPN, bo może faktycznie masz blokadę portów, ale po stronie ISP z którego korzysta router/serwer (chyba, że to jest to łącze mobilne, wtedy w standardzie nie da rady, pozostaje kontakt z Orange i prośba o włączenie/aktywację usługi VPN – chyba tak to się u nich nazywa, i da się, choć czasem trzeba podać dobry argument… ;-)).
Dawno nie dałem znaku życia, jakoś po prostu nie było czasu ;)
Postawiłem obraz Raspbiana Lite. Po rozszerzeniu partycji mam do wykorzystania ok. 700 mb. Mało, ale na razie więcej nie potrzebuję ;)
Co do łączności VPN przez Orange to sprawa wygląda tak – przez mobilny internet nie jestem w stanie się podłączyć do swojej sieci. Wygląda to tak, jakbym miał zablokowane porty w routerze, choć mam je odblokowane + protokół GRE. Natomiast kiedy jestem podłączony do jakiegokolwiek WiFi, do jakiego mam dostęp – łączność nawiązuję bez problemu.
Problem jest również gdy udostępniam Internet telefonem na tablet z Windowsem – sytuacja jest identyczna. Nie da się połączyć i już.
Nie ma teraz mobilnego internetu Orange, więc nie przetestuje, ale z tego co pamiętam (będzie już kilka lat wstecz) to na Orange w ofertach głosowych działało (coś mi się kojarzy, że w przypadku OFnK tez nie było problemu). Na pewno działa w Play i Virgin Mobile (aktualnie korzystam), choć tu też mam na myśli taryfy głosowe, nie wiem jak z taryfami typu DATA.
Nie ma wyjścia – dzwoń do Orange, ew. zapytaj ich na Facebooku – z tego co kojarzę, to starają się tą droga odpisywać szybko i sprawnie. Bo może jednak w Orange coś blokują w standardzie, i wtedy przy odpowiedniej argumentacji jest spora szansa, że przeniosą Cię do innej grupy (inny APN, np. grupa/usługa VPN).
Ew. wieczorem może uda mi się przetestować u siebie, bo kolega ma abonament w Orange, a do tego 2 inne karty w tej sieci… :-)
No i małe testy za nami, i wygląda na to, że jest OK. Zobacz może (np. Telnet) czy z telefonu „po Orange” możesz połączyć się z portem 1723.
No i wszystko już jest jasne.
Skierowałem się z pytaniem na fanpage Orange. Po minucie dostałem odpowiedź, że żeby pokorzystać sobie z VPN muszę być klientem biznesowym…
Masz Ci los. Byłem przekonany, że coś mi się należy od życia, skoro im płacę jałmużnę co miesiąc za abonament, hehe.
Dlatego tak nieśmiało sugerowałem (nie zawsze mogę wszystko pisać wprost), by kontaktować się z Orange, i przedstawić im dobre argumenty (np. pa, pa…) za tym, by uruchomili u Ciebie odpowiednią usługę (oznacza to m.in. inny APN ;-)), i jest możliwe nawet w przypadku cywili… Dla porównania – w Play (taryfy biznesowe) i Virgin Mobile (PrePaid) połączenie do VPN działa w standardzie.
U mnie na Pi 2 połączenie trzyma już kilka dni (jeden połączony komputer na win7 jeden na ubuntu) Ale zdarza mi się faktycznie, że na tablecie z win 8.1 z kartą Play po kilku godzinach VPN pada. Co do Raspbiana lite, to nie jest to po prostu raspbian bez GUI??? Niby lite mieści się na karcie 2GB, ale szybko robi się ciasno.
Nadal nie wiem jak rozwiązać problem z kilkoma połączeniami z jednej sieci.
Mam malinę wpiętą w biurze z publicznym adresem, ale kiedy Z DOMU chcę podpiąć się więcej niż jednym urządzeniem to udaje się to tylko pierwszemu. Nie wiem czy znaczenie ma to że jako łącza podstawowego do internetu używam LTE Cyfrowego Polsatu. Łącząc się z innych sieci np. sklep z internetem na kartę czy telefon z androidem, czy tablet z win8.1 wszystko chodzi razem bez problemu. Czy to któryś z domowych routerów nie puszcza połączenia, czy może jakiś błąd przy konfigu maliny.
Nigdy nie korzystałem z Raspbiana Lite – więcej, nawet się nim nie interesowałem, bo i tak każą Maline uzbrajam w kartę minimum 8 GB, a teraz to chyba nawet podstawowego Raspbiana nie da się wgrać nawet na 4 GB (na szczęście ceny kart, powiedzmy 8-16 GB są na tyle przyjemne, że w większości przypadków nie ma co się szczypać, chyba, że faktycznie niewiele tam planujemy dodawać).
Ale to router LTE CP masz w domu, i jak 2 urządzenia korzystają z internetu LTE CP (pewnie ich router), i próbują się połączyć do VPNa w pracy, to na raz działa Ci tylko jedno? Ale jak do tego samego VPNa w pracy połączysz się jednym urządzeniem z LTE CP, a drugim np. za pomocą innego ISP to jest wszystko OK?
Z tego co kojarzę/pamiętam, to w normalnej sytuacji na podstawie portu (serwer VPN) i adresu IP (klienta) tworzony jest identyfikator (chyba CallerID, czy jakoś tak to się nazywa). W sytuacji, gdy 2 (lub więcej) urządzeń mają ten sam identyfikator (w Twoim przypadku wspólny IP klienta (zresztą port też)) to być może dochodzi do konfliktu (złe pakiety, do złych urządzeń, ogólnie NAT głupieje) i dlatego kończy się to rozłączeniem pierwszego urządzenia.
W takim przypadku poszukaj informacji o:
Spojrzałem też do swoich notatek na temat VPN/PPTP i mam tam zapis o NAT, choć nie pamiętam teraz, czy to akurat to o co chodzi:
I wklej tam:
Teraz restart Pi (serwera, lub sama sieć) i może to będzie to…
Zawsze zostaje wypasiony router z edytorem NAT, albo… nie wiem, dwa serwery VPN na różnych portach, lub połączenie VPN między samymi routerami (ew. chyba zadziała między routerem w domu i serwerem VPN w pracy), ale tu ponownie wracamy do „wypasionych routerów”, ew. DD-WRT/OpenWRT lub coś w tym stylu.
Innym problemem – tak byś się nie nudził – może być to, że niektóre routery (zwłaszcza „do domu”) mają ograniczenie co do ilości połączeń VPN (danego typu, np. PPTP) w tym samym czasie do jednego połączenia – ale skoro działa Ci połączenie z pracą 2 klientów z zewnątrz, to Twój router w pracy najwidoczniej nie ma tego ograniczenia (przynajmniej do jednego połączenia), ale już np. router LTE CP może mieć jakieś tego typu ograniczenie.
Sprawa jest o tyle skomplikowana, że zanim klienci z domu połączą się z internetem, cały ruch przechodzi przez jeszcze jeden router (w zasadzie dwa, ale mniejsza z tym) z zainstalowanym pfSense (musiałem do niedawna mieć dwa połączenia WAN).
Nie wiem czy nie załatwię tego w ten sposób że kupię jakąś malinę pierwszej generacji i z niej nie zrobię klienta, i przez nią puszczę ruch. Co do routera w pracy to jest to jeden z tańszych TPlink’ów. Niestety pfSense niema domyślnego klienta VPN PPTP (choć ma serwer) więc instalacja jakiegoś na razie odpada.
Zresztą to co napisałeś podpowiedziało mi kolejny pomysł, sprawdzić czy nie puszcza HUAWEI polsatu, czy pfSense. Dzięki za pomoc
Witam
czy istnieje możliwość zmiany portu na inny niż 1723?? jeśli tak to w którym miejscu w konfiguracji na raspberry pi można to zrobić?
Jakaś możliwość na pewno istnieje, choć nie będzie to chyba takie proste – z tego co kojarzę, to PPTP nie ma w swojej konfiguracji takiego parametru jak port (choć chyba w niektórych systemach można coś tam zmienić w pliku /etc/services). Jeśli serwer VPN znajduje się za routerem (NAT), to zawsze możesz tu dokonać przekierowania portu WAN-LAN. Jeśli serwer VPN jest podłączony bezpośrednio do internetu, to możesz spróbować za pomocą „iptables” skonfigurować pewnego rodzaju przekierowanie.
Witam,
wykonalem wszytko krok po kroku ale niestety nie działą
byc moze dlatego ze zrobilem to na armbianie na orangepi
Ciężko mi powiedzieć, czy to faktycznie może być wina „armbianie na orangepi”, bo nigdy nie korzystałem. A jakie masz komunikaty/objawy?
Witam ponownie.
Może pomoże przygotowana pod linkiem historia konfiguracji:
https : / / zapodaj . net / 4ad68e15d4374.png . html
(proszę usunąć spacje z linku)
dziękuje za zainteresowanie i pomoc.
ok udało mi się uruchomić już serwer i nawet połączyć ale tylko z androida w WIN10 niestety nie… a wczesniej bład popełniłem w ms-dns gdzie podalem ip OrangePI a nie Routera… teraz trzeba przewalczyć WINDOWS10 bo nie chce sie połaczyć.
Fajnie, ze z Androida się udało. Dopiero teraz mam chwilę, by zerknąć w komentarze. Co do Windowsa 10 to z tego, co pamiętam, to nie miałem z nim problemów (natomiast obecnie nie korzystam, bo mam tymczasowo internet mobilny ze wszystkimi jego „urokami” ;-)). Zobacz w logi systemowe na Pi (szukaj tych związanych z VPN/PPTP), bo jest spora szansa, że tam znajdziesz odpowiedź.
Witam.
Dzięki za poradnik.Działa
Urządzenie otrzymuje adres ip z puli jaką przydzieliłem w pliku ale mam jedno pytanie: Jak sprawić aby możliwe było przeglądanie internetu korzystając właśnie z tego połączenia? Tak aby było widoczny adres ip mojej sieci domowej a nie np operatora komórkowego czy też innego ISP.
Bo jak na razie to jestem wstanie podłączyć urządzenie do sieci vpn, robić pingi oraz wszystko to co jest możliwe tak jak było by fizycznie w domu w sieci za routerem.
Chyba, że ja nie rozumiem na czym polega vpn ;)
Zerknij do sekcji „reguły firewalla” w artykule, i daj znać, czy pomogło…
Bez zmian.
Dodam, że jest to Rpi 4b
Lista firewall’a: http://www.wklejto.pl/761725
Witam. W sekcji konfiguracja firewalla jest ważna informacja.
„sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE” jeśli ktoś ma rasberry podłączone po wifi musi tutaj zmienić z eth0 na wlan0 i wtedy będzie działało. W przeciwnym razie dostęp jest tylko do sieci w której jest rasberry.
Dzięki za informację. Dodam jutro do artykułu, bo faktycznie w nowych malinach WiFi jest już standardem, więc może się to przydać.