Wpis z mikrobloga

@jurny_juhas: ...ale przeciez to tunel po SSLu, pojedyncze polaczenie, wiec jest malo wymagajace... blukujesz porty w kierunku na zewnątrz? Skąd wiesz, że to wina routera a nie problem z negocjacją? Jakieś logi z klienta czy inny tcpdump?
  • Odpowiedz
@jurny_juhas: ...z tych logów niewiele wynika, poza tym ze nie moze wynegocjowac polaczenia. Jak nie blokujesz portów w kierunku na zewnątrz to linux nie bedzie niczemu winny. A konfiguracje klienta masz prawidłową, z innej sieci Ci to działa? Na pewno po UDP i na pewno dobre haslo/certyfikat? Jak sie da to sobie odpal klienta w trybie debug, zeby mozna bylo cos wyczytac z tych logow...
  • Odpowiedz
@jurny_juhas: Ja bym Ci proponował na dowolnym innym serwerze odpalić netcata na udp i porcie 1194, od siebie połączyć się do niego telnetem i zobaczyć czy komunikacja idzie w obie strony. Jak nie, to musisz to poprawić, jak tak to wina pewnie czegoś w robocie.
  • Odpowiedz
@FalseIdeas: już wiem, że to nie kwestia z mojej strony. Spróbowałem połączyć się z VPN przez telefon (zrobiłem teethering na laptopa) i też nie chce działać. Kwestia więc zostaje po stronie serwera vpn i administratora sieci.
  • Odpowiedz
@jurny_juhas: Dlatego pytałem o pinga, z loga wynika, że albo nie masz łączności z adresem albo dany port jest zamknięty albo firewall nie przepuszcza na niego ruchu. Tak czy owak po stronie serwera szukałbym przyczyny. To w ogóle działało Ci i przestało? Pierwszy raz próbujesz zestawić?
  • Odpowiedz
@Nawry: wczoraj uzyskałem dopiero dane dostępowe, więc próbowałem zestawić połączenie pierwszy raz. Zobaczymy. Pogadam dziś z adminem, zweryfikuje o co chodzi. Bo nie działa na:

1. moim stałym łączu (ISP to Politechnika Łódzka)

2. Play
  • Odpowiedz
@jurny_juhas: TLS się pewnie wysypał w negocjacji bo była różnica w dacie certyfikatów. Temat przerabiałem wielokrotnie i zawsze się pojawia - daty certyfikatów nie zgadzają się z czasem rzeczywistym na maszynie lub vice versa.
  • Odpowiedz