Polskie Forum Synology

: **sob lip 09, 2022 7:25 pm**

Mam problem z połączeniem się do serwera OpenVPN na DS920+. Serwer podłączony jest do routera ZTE MC801A 5G. Adres DS920+ w routerze jest dodany do DMZ oraz jest ustawione przekierowanie portu 1194 na adres serwera. Z kolei na serwerze w ustawieniach firewalla port 1194 jest otwarty. Serwer ma skonfigurowany DDNS i przez niego próbuję się łączyć. Poniżej ustawienia klienta VPN:

Kod: Zaznacz cały

dev tun
tls-client
remote xxxxx.synology.me 1194
script-security 2
reneg-sec 0
cipher AES-256-CBC
auth SHA512

Poniżej logi z klienta VPN:

Kod: Zaznacz cały

Sat Jul 09 19:05:12 2022 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Sat Jul 09 19:05:12 2022 OpenVPN 2.5.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jun 17 2021
Sat Jul 09 19:05:12 2022 Windows version 10.0 (Windows 10 or greater) 64bit
Sat Jul 09 19:05:12 2022 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Sat Jul 09 19:05:16 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Jul 09 19:05:16 2022 UDP link local (bound): [AF_INET][undef]:1194
Sat Jul 09 19:05:16 2022 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Jul 09 19:06:16 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Jul 09 19:06:16 2022 TLS Error: TLS handshake failed
Sat Jul 09 19:06:16 2022 SIGUSR1[soft,tls-error] received, process restarting
Sat Jul 09 19:06:21 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Jul 09 19:06:21 2022 UDP link local (bound): [AF_INET][undef]:1194
Sat Jul 09 19:06:21 2022 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194

Na serwerze postawiona jest maszyna wirtualna, z której próbuję poleceniem tnc sprawdzić otwarcie portów. Tak więc port 1194 jest zamknięty zarówno gdy próbuję wykonać polecenie tnc na adres ZTE jak i na adres DS920+. Próbowałem wyłączyć całkowicie firewall zarówno na Synology jaki na maszynie wirtualnej, ale to nic nie zmieniło. Nie wyłączyłem firewalla na ZTE, bo nie ma tam takiej opcji, choć tak jak pisałem adres Synology jest ustawiony jako DMZ więc to nie powinno być problemem. Kontrolnie próbowałem również wykonać polecenie tnc z maszyny wirtualnej na adres ZTE na porcie 443 i wtedy komunikacja jest. Tylko dlaczego mam ciągle zablokowany port 1194 pomimo ustawienia wszystkich możliwych przekierowań portu 1194 a nawet wyłączenia firewalli.

Internet mam mobilny od Playa, 4G. Dzwoniłem do nich dwa razy, ale twierdzą, że żadnego ruchu nie blokują i porty powinny być otwarte. Co mogłem przeoczyć albo zrobić źle?

: **sob lip 09, 2022 7:48 pm**

Bardzo możliwe, że Play blokuje komunikację na UDP. To normalne u mobilków. Zmień konfigurację na połączenie za pomocą TCP i ponów próby.

: **sob lip 09, 2022 9:41 pm**

To niestety nie pomogło. Tak teraz wygląda konfiguracja:

Kod: Zaznacz cały

dev tun
tls-client
remote-cert-tls server
remote xxx.synology.me 1194
pull
proto tcp-client
script-security 2
reneg-sec 0
cipher AES-256-CBC
auth SHA512

a tak wygląda log połączenia:

Kod: Zaznacz cały

Sat Jul 09 21:34:56 2022 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Sat Jul 09 21:34:56 2022 OpenVPN 2.5.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jun 17 2021
Sat Jul 09 21:34:56 2022 Windows version 10.0 (Windows 10 or greater) 64bit
Sat Jul 09 21:34:56 2022 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Sat Jul 09 21:35:01 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Jul 09 21:35:01 2022 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.xxx:1194 [nonblock]
Sat Jul 09 21:37:02 2022 TCP: connect to [AF_INET]xxx.xxx.xxx.xxx:1194 failed: Unknown error
Sat Jul 09 21:37:02 2022 SIGUSR1[connection failed(soft),init_instance] received, process restarting
Sat Jul 09 21:37:07 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Jul 09 21:37:07 2022 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.xxx:1194 [nonblock]

Wydaje mi się, że problem chyba leży gdzieś w zdalnej sieci LAN. Dziwi mnie dlaczego komputer w sieci zdalnej nie jest w stanie ani na routerze ani na serwerze połączyć się z portem 1194. Co może go jeszcze blokować skoro nawet wyłączałem wszystkie możliwe firewalle?

: **pn lip 11, 2022 8:49 am**

Witam

Moje propozycje do sprawdzenia/przetestowania:
1. Może w tym przypadku dla Autora wątku to oczywista oczywistość. Jednak jak przy okazji podobnych topiców po raz kolejny raz zapytam:
czy łącze gdzie znajduje się serwer na pewno posiada publiczny adres IP? Bo bez tego z dostępu z "zewnątrz" nici (czasem może robić przekierowania dostawca na swoich urządzeniach, ale to raczej rzadkość. No i trzeba się prosić...)
2. Jeśli to możliwe - sprawdzić klienta OpenVPN w sieci lokalnej, tej samej gdzie jest serwer. Powinien normalnie się połączyć. Ewentualnie w konfiguracji wpisać adres IP LAN serwera. Czyli np.:

Kod: Zaznacz cały

remote 192.168.100.1 port

3. Spróbować zmienić port z domyślnego 1194 na inny, np. 8080. (nawiasem w OpenVPN podoba mi się właśnie to, że można zmienić port oraz do działania wystarczy tylko jeden).
4. W topicu było o zmianie z UDP na TCP. Może to trywialne, ale zmianę trzeba zrobić także po stronie serwera OpenVPN.
5. Można też testowo na chwilę zrobić przekierowanie na port DSM w Synku. Chodzi mi tylko o sprawdzenie poprawności działania przekierowań i dostępu do serwera z "zewnątrz".
6. Spróbować rozwiązanie typu TailScale, które nie wymaga żadnych przekierowań, publicznego IP, itp., ale ja tego nie ćwiczyłem. Zobacz topic:
viewtopic.php?t=3724

EDIT
Jeszcze a'propos tego fragmentu logu:

Kod: Zaznacz cały

Sat Jul 09 21:35:01 2022 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.xxx:1194 [nonblock]
Sat Jul 09 21:37:02 2022 TCP: connect to [AF_INET]xxx.xxx.xxx.xxx:1194 failed: Unknown error

Zrobiłem z ciekawości mały test u siebie. Jeżeli w konfiguracji podam różne porty (tzn. inny w kliencie niż na serwerze), otrzymuję identyczny
"Unknown error", oraz na jego pojawienie także trzeba czekać około 2 minuty po "Attempting to establish...". Tak samo jeżeli w ogóle wyłączę serwer OpenVPN...
Wniosek mój taki, że przyczyny owego "Unknown error" niewiele można wywnioskować oraz pojawia się chyba niemal w każdej sytuacji problemu z połączeniem... Może coś z przekierowaniami na routerze, może jakiś firewall blokuje, może coś jeszcze innego...
"Unknown error" = "Serwer OpenVPN jest nieosiągalny" - tak bym to przetłumaczył

Konkretny błąd otrzymałem tylko gdy (celowo) w konfigu klienta podałem nieprawidłowy adres hosta (np.xxy.synology.me zamiast xxx) Wówczas przy nawiązywaniu połączenia natychmiast dostałem komunikat:

Kod: Zaznacz cały

RESOLVE: Cannot resolve host address: xxy.synology.me:port (Nieznany host. )

ale jak widać u Ciebie to nie jest to.

EDIT 2
Qrczę, jakieś zaćmienie, nie zauważyłem tego:

HemaN pisze: ↑sob lip 09, 2022 7:25 pm Internet mam mobilny od Playa, 4G. <...> Co mogłem przeoczyć albo zrobić źle?

W takim razie jeszcze raz pytam o publiczny IP ...
Coś nie mam dobrych przeczuć... Np. topic tutaj, post #3:
https://www.elektroda.pl/rtvforum/topic3727796.html
No chyba, że coś się zmieniło w Playu w ciągu niecałych 2 lat.

: **pn lip 11, 2022 6:46 pm**

Cześć,

dzięki za rady. Serwer posiada skonfigurowanego DDNSa w domenie synology.me. W pliku konfiguracyjnym OpenVPN wpisuję nazwę DDNS i potem widzę, że jest dobrze rozwiązywana, bo w logach klienta OpenVPN pojawia się zewnętrzny adres IP serwera.

Pomysł ze sprawdzeniem openvpn w sieci lokalnej jest dobry, nie przyszło mi to do głowy. Przy najbliższej możliwej okazji sprawdzę to, to samo ze zmianą domyślnego portu, też muszę spróbować. Dostęp do serwera z zewnątrz działa, bo mogę się bez problemu zalogować poprzez quickconnect.to.

Porty na pewno są te same, tj 1194. Ale tak jak pisałem wyżej spróbuję zmienić na jakiś wyższy port.

Dam znać gdy wykonam powyższe sprawdzenia.

EDIT: Zmiana portu nie pomogła. W Orange nie było takich problemów, trzeba było jedynie zadzwonić i poprosić o odblokowanie portu, ewentualnie wyłączenie firewalla i wszystko śmigało, nawet bez statycznego IP.

EDIT 2: Odpaliłem Wiresharka u siebie i na maszynie wirtualnej w sieci zdalnej. Widać, że wychodzą u mnie pakiety na zewnętrzny adres IP serwera, ale w sieci zdalnej nie przychodzą żadne pakiety z mojego publicznego adresu IP. Jeszcze raz kontaktowałem się z Play, tym razem przez czat. Zarzekają się, że nie ma żadnej blokady po ich stronie i cały ruch powinien przechodzić na każdym porcie. Zaczynam mieć wrażenie, że to modem ZTE nie przepuszcza ruchu. W tym modelu nie ma opcji VPN passthrough, choć dodanie serwera do DMZ powinno teoretycznie puścić cały ruch.

: **pn lip 11, 2022 9:36 pm**

HemaN pisze: ↑pn lip 11, 2022 6:46 pm Cześć,

dzięki za rady. Serwer posiada skonfigurowanego DDNSa w domenie synology.me. W pliku konfiguracyjnym OpenVPN wpisuję nazwę DDNS i potem widzę, że jest dobrze rozwiązywana, bo w logach klienta OpenVPN pojawia się zewnętrzny adres IP serwera.

Okej, ja to rozumiem. Sam też używam DDNS od Synology

Pytanie tylko czy adres IP (rozwiązany po wpisaniu xxx.synology.me), z którym próbujesz się połączyć, jest rzeczywiście publicznym adresem na porcie WAN routera łączącego Twój LAN z internetem (chodzi oczywiście o sieć, gdzie stoi serwer), czy należy do jakiegoś innego urządzenia brzegowego operatora.
Najprościej moim zdaniem sprawdzić (chyba, że ktoś ma inny pomysł...), wchodząc na stronki pokazujące publiczny adres naszego łącza, ot choćby
https://www.speedtest.net/ czy https://nordvpn.com/pl/what-is-my-ip/
i porównać, z adresem przydzielonym na porcie WAN routera. Jeżeli są takie same - na naszym łączu/routerze mamy faktycznie "publika".

Powiem może w ten sposób: nie jestem abonentem Playa. Jednak z szybkiego rozeznania wynika, że nie świadczy publicznych IP. Nawet znalazłem petycję abonentów

https://www.petycjeonline.com/publiczne ... w_play_lte
Jak jest dokładnie w chwili obecnej, tego nie wiem. W końcu Ty jesteś abonentem/użytkownikiem tego dostawcy i powinieneś wiedzieć (lub się dowiedzieć), jakiego rodzaju przydziela IP (publiczny/prywatny). Bo to wciąż nie jest dla mnie jasne.
Nadal też uważam, że bez "prawdziwego publicznego IP" cała operacja z dostępem do własnego serwera VPN się nie uda (bez dodatkowego angażowania operatora, co w przypadku takiego molocha jak Play raczej jest bliskie zeru). No chyba, że jest jakiś inny sposób, z chęcią poznam. Oczywiście pomijam tu rozwiązania z użyciem dodatkowych zewnętrznych serwerów, czy typu TailScale, bo to insza inszość.

EDIT
Nie znam routera ZTE. Jednak czy nie można robić na nim po prostu przekierowań portów: np. przychodzący 1194 -> na prywatny 1194, 192.168.100.1 (adres serwera w LAN, przykładowy). No i czy można podejrzeć IP przydzielane przez operatora na porcie WAN?

: **pn lip 11, 2022 10:07 pm**

Sprawdziłem te adresy. I to właśnie tu jest pewnie problem. Adres w zakładce dostęp zewnętrzny>DDNS jest taki sam jak ten, który pokazuje strona canyousemee.org gdy wchodzę na nią z maszyny wirtualnej w sieci zdalnej. Ale port WAN w ZTE ma inny adres, więc tak jak piszesz pomiędzy tymi adresami jest infrastruktura sieciowa i pakiety gdzieś tam giną. I tu znowu przyznam Ci rację, bo pewnie wywalczenie czegoś z Play w takiej sytuacji będzie w zasadzie niemożliwe.

ZTE ma możliwość przekierowania portów i od razu je przekierowałem na adres serwera w LAN. Ale tak jak już wynika z powyższego i ze sprawdzenia Wiresharkiem pakiety po prostu nie dochodzą do ZTE.

Chodzi mi jeszcze po głowie reverse proxy po porcie 443. Skoro DDNS się przebija, to znaczy, że jest jakiś sposób. Problem w tym, że już wielokrotnie próbowałem skonfigurować reverse proxy na Synology przy innych okazjach i nigdy nie działał :/ . może ktoś poda jakiś dobry tutorial do reverse proxy na Synology

?

: **pn lip 11, 2022 11:03 pm**

HemaN pisze: ↑pn lip 11, 2022 10:07 pm Sprawdziłem te adresy. I to właśnie tu jest pewnie problem. Adres w zakładce dostęp zewnętrzny>DDNS jest taki sam jak ten, który pokazuje strona canyousemee.org gdy wchodzę na nią z maszyny wirtualnej w sieci zdalnej. Ale port WAN w ZTE ma inny adres, więc tak jak piszesz pomiędzy tymi adresami jest infrastruktura sieciowa i pakiety gdzieś tam giną. I tu znowu przyznam Ci rację, bo pewnie wywalczenie czegoś z Play w takiej sytuacji będzie w zasadzie niemożliwe.
<...>

Tak żeby było jasne: nie jestem profesjonalnym specem od sieci

Myślę jednak, że u Ciebie zachodzi sytuacja opisana w tym artykule lub bardzo podobna. Tłumaczenie chyba maszynowe, trochę po polskiemu, ale idzie zrozumieć o co biega:
https://www.informatique-mania.com/pl/l ... -a-savoir/
Są także opisane inne sposoby sprawdzenia czy mamy/nie mamy "publika".

Sądzę, że niestety nic z tym nie zrobisz. Mam na myśli "klasyczne" rozwiązania z przekierowywaniem portów, itp.
Teoretycznie, ale zupełnie teoretycznie dostawca w takim układzie mógłby założyć przekierowanie portu (np. 1194) z routera oznaczonego na rysunku "CGN" (87.87.87.87), na Twój ZTE (na rysunku np. "R1" 100.64.0.1), a Ty z kolei przekierować 1194 z tego routera na swój serwer. W przypadku dostawcy typu Play raczej marnie to widzę

Może zatem przyjrzyj się temu TailScale?

EDIT
Jeszcze jedno. Napisałeś:

HemaN pisze: ↑pn lip 11, 2022 10:07 pm Skoro DDNS się przebija, to znaczy, że jest jakiś sposób.

Nie bardzo rozumiem, co masz na myśli "DDNS się przebija". DDNS owszem "wykrywa" publiczny adres z jakim Twój NAS łączy się do internetu, lecz jak ustaliliśmy, nie jest to adres WAN Twojego routera ZTE, tylko innego urządzenia dostawcy, rzeczywiście podłączonego do Globalnej Sieci. Odnosząc się znów do przykładowego rysunku z powyższego artykułu, będzie to router "CGN", IP=87.87.87.87. Zatem wszystkie połączenia/pakiety adresowane na heman.synology.me (załóżmy tak masz zarejestrowaną domenę w DDNS) trafią do IP=87.87.87.87. A dalej... donikąd, bo router CGN nie będzie wiedział co z nimi robić.

I jeszcze to mi umknęło:

HemaN pisze: ↑pn lip 11, 2022 6:46 pmDostęp do serwera z zewnątrz działa, bo mogę się bez problemu zalogować poprzez quickconnect.to.

Quickconnect działa na zupełnie innej zasadzie. Nie wymaga publicznego IP, ani od użytkownika umiejętności konfiguracji routerów, przekierowań portów, itp. W ogóle user w zasadzie nic nie musi wiedzieć o sieciach, adresach, publicznych, prywatnych itd.

Połączenia są nawiązywane przez serwery Synology. Minus jest taki, że w przypadku gdy serwery Synology zaczną szwankować, z Quickconnect stanie się to samo. Kolejna sprawa, że dane wędrują właśnie przez "jakieś-tam-gdzieś" serwery i pytanie na ile są bezpieczne - to już kwestia zaufania. I następna: QC pozwala na dostęp tylko do pewnych usług na serwerze NAS, np. mogę się dostać do DSM, audio/video/foto/file/note/drive Station. Ale np. zamapować dysku sieciowego już nie (przynajmniej ja nie potrafię), co przez VPN nie stanowi problemu. Poza tym przez VPN mogę się dostawać do innych urządzeń w moim LAN, np. dekodera satelitarnego, lub czegokolwiek innego.

Co do proxy nie pomogę, szczerze pisząc nie drążyłem tematu. Niemniej myślę, że nie rozwiąże to problemu. Bo jak zmusić router CGN 87.87.87.87, aby pakiety przychodzące na jego WAN i port np.1194 kierował do Twojego routera? Skoro do konfiguracji CGN nie masz dostępu?

Załączam rysunek z artykułu, bo linki zdarzają się znikać.

CG-NAT.jpg

: **wt sie 09, 2022 10:06 pm**

Musiałem na kilka tygodni zostawić ten temat z braku czasu, ale wracam do niego. Dzięki @stanley99 za link. Po przeczytaniu artykułu już wiem, że adres WAN IP mojego ZTE jest w CG-NAT, mieści się w zakresie od 100.64.0.1 do 100.127.255.254. Czyli tak jak piszesz marne szanse, aby ktoś w Play przekierował mi ruch na mojego ZTE. Po kilku już telefonach i wielokrotnych prośbach o kontakt do kogoś z wiedzą techniczną z kim mógłbym porozmawiać daję chyba spokój, to jest walenie głową w mur.

Pobawiłem się OpenVPN wewnątrz LAN i w tym momencie łączy się bez problemu. Niestety z zewnątrz dalej nie działa, ale tym razem dla odmiany dostaję błąd:

Kod: Zaznacz cały

TCP: connect to [AF_INET]XXX.XXX.XXX.XXX:1194 failed: Unknown error.

Na ten moment wydaje mi się, że jedyną opcją, żeby to zadziałało to zmiana beznadziejnego operatora. W innej firmie bez problemu ustawiłem działający serwer OpenVPN (internet mobilny w Orange), wystarczył jeden telefon na infolinię i prośba albo o puszczenie ruchu na porcie albo o całkowite wyłączenie firewalla po ich stronie i wszystko śmiga od kilku lat, nawet nie musiałem prosić o dodatkową usługę statycznego adresu IP.

Dzięki za porady.

: **śr sie 10, 2022 6:32 am**

HemaN pisze: ↑wt sie 09, 2022 10:06 pm<...>
Na ten moment wydaje mi się, że jedyną opcją, żeby to zadziałało to zmiana beznadziejnego operatora. <...>

A koniecznie musi być OpenVPN? Może wypróbuj Tailscale, który podobno pozwala łączyć się "z zewnątrz" mimo braku publicznego IP?
Piszę "podobno", ponieważ osobiście nie ćwiczyłem TS.
Patrz p.6 w poście z 11.07, 8:49

Polskie Forum Synology

Nie mogę się połączyć przez OpenVPN

Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN

Re: Nie mogę się połączyć przez OpenVPN