Sieć: rt-n66u (server vpn) na neostradzie <--> rt-n10u (klient vpn) na łączu 3g
Neostradę mam ustawioną aby codziennie o 6 rano restartowała połączenie. Po tym restarcie klient nie łączy się do serwera (w logach jest tylko oczekiwanie na połączenie) i dopiero jak na kliencie zrestartuje się połączenie to następuje zestawienie tunelu. W drugą stronę nie ma to znaczenia. Dzisiaj adres na kliencie zmienił się kilka razy, ale połączenie się zestawia. Natomiast rano od godz. 6 (restart neostrady) do 9 (zmiana adresu na kliencie) vpn się nie zestawił.
Teoretycznie mogę ustawić aby klient resetował połączenie chwilę po serwerze... ale problem w tym że jeśli serwer na chwilę padnie (np zanik napięcia) to po uruchomieniu ten tunel już się nie zestawi, aż do restartu klienta.
Proponuję Ci przeanalizować wszystko od początku.
Osobiście też zestawiałem takie połączenie w takiej konfiguracji jak twoja z tym że na 2 x RT-N10U i kłopotów nie ma.
Czekam na dostawę drugiego rt-n10u, żeby skonfigurować drugi taki tunel, z tym że ten będę miał w domu do testów, więc sprawdzę to dokładnie, skoro piszesz że nie masz takich problemów...
Teoretycznie wszystko jest ok, bo jak sprawdzałem z lokalizacji 3g, to po wpięciu laptopa do przekierowanego portu, on normalnie dostawał ip z servera i mogłem się logować na router z adresu lokalnego, tylko te braki zestawień mnie zastanawiają.
Najgorsze są te prywatne adresy od orange, nie mogę się logować zdalnie na ten odległy router.
Może to wina tomato?
Sprawdź wersję v116 czy na niej jest wszystko ok.
Ja osobiście miałem pewne problemy z konfiguracją ale wszystko udało się ogarnąć i teraz działa.
Przejrzyj konfigurację bo jak się przekonałem nie raz mała literówka itp może spowodować niezłe problemy
Dzisiaj spróbuję zestawić tunel na kolejnym routerze. Zobaczę jak to będzie działać. Jak będzie to samo to wgram wcześniejszą wersję, być może będzie to jakieś rozwiązanie... w/g changeloga w wersji 119 była aktualizacja openvpn, może coś się popsuło, albo inaczej działa i dlatego takie są akcje.
Połączony z 11 wrzesień 2014 19:55:59:
No więc tak...
Postawiłem drugi serwer vpn na rt-n66u. Podpiąłem do niego klienta przez 3g (mam go u siebie w domu - rt-n10u), do przekierowanego portu wpiąłem router na openwrt (dostał adres z dhcp rt-n66u).
W logach vpn po "Initialization sequence completed" nie ma nic - to dobrze czy nie? Dla porównania pierwszy serwer (do którego jest wpięty taki sam router - ale nie mam go w domu) co chwilę w logach pisze że zestawia połączenie.
Logi serwera do którego podpiętego klienta mam w domu (wykonałem w tym czasie 2000 pingów wszystkie wróciły od klienta)
Logi serwera do którego podpięty klient jest w innej lokalizacji.
Cytat
Thu Sep 11 19:42:40 2014 TUN/TAP TX queue length set to 100
Thu Sep 11 19:42:40 2014 Listening for incoming TCP connection on [undef]
Thu Sep 11 19:42:45 2014 TCP connection established with [AF_INET]31.61.140.65:17512
Thu Sep 11 19:42:45 2014 TCPv4_SERVER link local (bound): [undef]
Thu Sep 11 19:42:45 2014 TCPv4_SERVER link remote: [AF_INET]31.61.140.65:17512
Thu Sep 11 19:43:45 2014 Inactivity timeout (--ping-restart), restarting
Thu Sep 11 19:43:45 2014 Closing TUN/TAP interface
Thu Sep 11 19:43:45 2014 SIGUSR1[soft,ping-restart] received, process restarting
Thu Sep 11 19:43:45 2014 Restart pause, 1 second(s)
Thu Sep 11 19:43:46 2014 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 11 19:43:46 2014 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 19:43:46 2014 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 11 19:43:46 2014 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 19:43:46 2014 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu Sep 11 19:43:46 2014 TUN/TAP device tap22 opened
Thu Sep 11 19:43:46 2014 TUN/TAP TX queue length set to 100
Thu Sep 11 19:43:46 2014 Listening for incoming TCP connection on [undef]
Thu Sep 11 19:43:51 2014 TCP connection established with [AF_INET]31.61.140.65:24220
Thu Sep 11 19:43:51 2014 TCPv4_SERVER link local (bound): [undef]
Thu Sep 11 19:43:51 2014 TCPv4_SERVER link remote: [AF_INET]31.61.140.65:24220
Thu Sep 11 19:44:51 2014 Inactivity timeout (--ping-restart), restarting
Thu Sep 11 19:44:51 2014 Closing TUN/TAP interface
Thu Sep 11 19:44:51 2014 SIGUSR1[soft,ping-restart] received, process restarting
Thu Sep 11 19:44:51 2014 Restart pause, 1 second(s)
Thu Sep 11 19:44:52 2014 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 11 19:44:52 2014 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 19:44:52 2014 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 11 19:44:52 2014 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 19:44:52 2014 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu Sep 11 19:44:52 2014 TUN/TAP device tap22 opened
Thu Sep 11 19:44:52 2014 TUN/TAP TX queue length set to 100
Thu Sep 11 19:44:52 2014 Listening for incoming TCP connection on [undef]
Thu Sep 11 19:44:57 2014 TCP connection established with [AF_INET]31.61.140.65:29627
Thu Sep 11 19:44:57 2014 TCPv4_SERVER link local (bound): [undef]
Thu Sep 11 19:44:57 2014 TCPv4_SERVER link remote: [AF_INET]31.61.140.65:29627
Thu Sep 11 19:45:57 2014 Inactivity timeout (--ping-restart), restarting
Thu Sep 11 19:45:57 2014 Closing TUN/TAP interface
Thu Sep 11 19:45:57 2014 SIGUSR1[soft,ping-restart] received, process restarting
Thu Sep 11 19:45:57 2014 Restart pause, 1 second(s)
Thu Sep 11 19:45:58 2014 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 11 19:45:58 2014 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 19:45:58 2014 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep 11 19:45:58 2014 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 19:45:58 2014 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu Sep 11 19:45:58 2014 TUN/TAP device tap22 opened
Thu Sep 11 19:45:58 2014 TUN/TAP TX queue length set to 100
Thu Sep 11 19:45:58 2014 Listening for incoming TCP connection on [undef]
Thu Sep 11 19:46:03 2014 TCP connection established with [AF_INET]31.61.140.65:15731
Thu Sep 11 19:46:03 2014 TCPv4_SERVER link local (bound): [undef]
Thu Sep 11 19:46:03 2014 TCPv4_SERVER link remote: [AF_INET]31.61.140.65:15731
Pingi z rt-n66u do openwrt idą, w drugą stronę również, ale nie mogę się zalogować na to openwrt ani przez www, ani przez ssh, ale jak podłączę telefon do wifi na openwrt to do rt-n66u mogę się zalogować - tak powinno być czy nie?
Tego w odległej lokalizacji nie mogę sprawdzić pingów, bo tam nic nie jest wpięte w przekierowany port (jak na razie), jednak kiedy go zestawiałem tydzień temu i wpinałem do portu lapa to też dostawał adres i net normalnie na nim działał.
Edytowany przez overflow2 dnia 11-09-2014 19:55
· Łącznie użytkowników: 24,115 · Najnowszy użytkownik: Ja
Czat
Musisz się zalogować, aby opublikować wiadomość.
Maniek91PL
06-11-2024 22:37
dzięki !
maxikaaz
29-10-2024 14:27
@Maniek91PL - Administration=> Admin Access, i tam masz "Allow Wireless Access" do zaznaczenia
Maniek91PL
26-10-2024 22:07
siemka! ktoś przypomni co się ustawiało jeśli nie mogę wejść od strony wifi do tomato? od lan działa
overflow2
04-10-2024 17:34
Kupowałem Asusy n10u albo n12d1 ale nie widzę ich, chyba już nie produkują, Chodzi o coś nowego i taniego. Transfery niewielkie.
maxikaaz
04-10-2024 09:38
@overflow2 patrząc po dostępności funkcji w nowych kompilacjach, to chyba nawet WRT54G/GL jeszcze ma OpenVPN, albo jakiś odpowiednik... zależy, na jakie transfery liczysz.
overflow2
30-09-2024 20:53
Jaki aktualnie najtańszy router do tomato do openvpn?
maxikaaz
27-07-2024 15:07
@servee - na początek router do rozebrania i obejrzenia, ciężko wróżyć tak tylko po objawach
maxikaaz
27-07-2024 14:55
@servee - cały kontroler nie pada tak sobie z powodu "zbiegu okoliczności", więc prawdopodobnie gdzieś przepięcie.
servee
25-07-2024 13:33
@maxikaaz: działało, aż pewnego pięknego dnia przestało działać. W tym dniu była też burza, ale to raczej zbieg okoliczności.
maxikaaz
25-07-2024 11:38
@servee - o ile problem jest w obrębie samych wyjść (dławiki, warystory), to naprawialne, ale jeśli w samym SoC - to nienaprawialne ze względu na koszta. A co było przyczyną?
' target='_blank'>Link
