Inea - przekierowanie portów blokowanie [Problem]


(maciej12203) #1

Witam . Mam taki problem i męczę się z tym już od miesiąca chyba albo dłużej .
W sieci lokalnej postawiłem serwer VPN dla testów - OpenVPN. Wszystko zostało skonfigurowane napewno poprawnie ,ponieważ było wszystko przeglądane po kilkanaście razy aby się upewnić czy napewno nie ma gdzieś błędu .
Wszystkie firewalle powyłączane dla testów , zarówno na klientach jak i na serwerze ( lecz tylko dla testów później będą dodane reguły ) wszystko działa lokalnie i jest bajka . Lecz zaczeły się schody kiedy chciałem połączyć się zewnętrznie . Zacząłem od zamówienia u swojego dostawcy ( INEA ) publicznego ip . Po 24H dostałem taki adres i rzeczywiście się zmienił także mam pewność ,że jest to publiczny . Następnie zacząłem od przekierowania portów , konfiguracja tego była tworzona na kilkanaście sposobów i sprawdzana przez pomoc techniczną INEA także mam pewność ,że wszystko było ok . Lecz przekierowanie portów nie zadziałało i pomimo zdefiniowania reguł porty nie reagują wogóle na przekierowanie tak jakby router pomijał wszystko co tam dodam . Skontaktowałem się z technikiem INEA i rozmawiałem z nim na ten temat i sam skonfigurował mi jeszcze raz dla pewności przekierowanie portów i dał pewność ,że przekierowanie będzie działać , lecz jest inaczej do dzisiaj nie jestem wstanie przekierować tych portów . Otwarty jest tylko standardowy port 80 reszta portów jest zamknięta i nie jestem w stanie ich w żaden sposób otworzyć .
Czy to normalne ,że INEA aż tak ingeruje w konfigurację i nie pozwala na takie rzeczy jak przekierowanie? Pomimo tego ,że mówią ,że oni nic nie blokują i wszystko jest dla użytkownika pootwierane tylko chyba tak nie jest ( Mój router to Huawei HG8247H ,który dostałem od nich ). Proszę o radę oraz dziękuję za wszelką udzieloną pomoc.


(MatX_) #2

Korzystam z tego samego ISP i mogę potwierdzić, że żadnych portów nie blokują.
Problemem może być sam router albo jego niewłaściwa konfiguracja.
Generalnie najlepiej zaopatrzyć się we własny router, wtedy masz pewność, że wszystko działa poprawnie.


(roobal) #3

W jaki sposób testujesz ten swój VPN? Łączysz się z własnego LANu na publiczne IP? Jeśli tak, to nie dziwne, że Tobie to nie działa, ponieważ żaden router nie zapętli Tobie pakietu, do tego łącząc się do VPNa (próbujesz robić podwójne zapętlenie).

Przetestuj działanie VPN z innej sieci, np. od kolegi, z jakiegoś otwrtego WiFi, z sieci komórkowej itp. Konfiguracja OVPN nie jest aż tak banalna jak się wydaje i tu naprawdę łatwo o pomyłkę. Zresztą jeśli masz błędy konfiguracyjne OVPN wyrzyga Ci to na konsoli/w logu.


(maciej12203) #4

VPN testowałem normalnie po adresie lokalnym kiedy chciałem sprawdzić czy wogole usługa działa i działała to zacząłem testować z zewnętrznej sieci zarówno u kolegi od wogole innego dostawcy jak i poprzez sieć komórkowa na Androidzie lub udostępniona siecią komórkową na laptopa . Sprawdzałem logi lecz nie znam się aż tak mocno na analizie tych logów , bo to dopiero mój początek z OpenVPN . Pisałem tez na oficjalnym forum w tej sprawie lecz za dużo to mi nie pomogło . A co wogole sądzicie o tym routerze od INEA ? Lepiej kupić nowy , lepiej zarządzany ?


(sadaj72) #5
  1. Może na routerze włączony jest firewall i blokuje wszelkie połączenia przychodzące
  2. Spróbuj aktualizacji firmware
  3. Niektóre routery mają funkcje source port randomization, wtedy trzeba osobno definiować reguły nat dla połączeń przychodzących i wychodzących (inbound/outbound nat).

(maciej12203) #6

Huawei HG8247H domyślnie po podłączeniu do portu WAN połączenia ( światłowodu ) pobiera od dostawcy konfigurację ,która blokuje niektóre czynności dla zwykłego użytkownika “root” dlatego też próbowałem odblokować dostęp do pełnego “Admina” i się udało , dla pewności czy to może nie jego wina wyłączyłem całkowicie firewalla ,lecz to nie przyniosło żadnego efektu bo połączenie VPN nadal tak jakby nie przechodziło. Nie znalazłem w tym trybie administrowania żadnej opcji związanej z NATem czy coś zwiazanego z portami . Odpowiadam tak dla zgodności


(roobal) #7

Zobacz w logach czy serwer w ogóle dostaje pakiety inicjujące połączenia.

Jeśli chodzi o OVPN, to on srednio lubi się z NATem.

Jaki ustawiłeś tryb pracy OVPN? TUN czy TAP (routing czy bridge)?

Co dostaje klient w logu przy próbie połączenia?


(maciej12203) #8

Tryb pracy OVPN w tym przypadku to TUN ( dev tun )
Poniżej podsyłam to co zwróciło client.ovpn czyli klient
logiklient.txt (23,5 KB)

Nie zwracajcie uwagi na porty z jakimi się łącze , ponieważ próbowałem kilka opcji i jest to konfiguracja jedna z kilku. Łączyłem się zarówno na porcie 80 ( który jest otwarty w moim przypadku jako jedyny co jest raczej logiczne ) tak i porty 1194 ( standardowy OVPN ) oraz jakieś przykładowy 5000 żaden z nich nie dał się otworzyć , przekierować .


(maciej12203) #9

Poniżej podsyłam to co zwróciło po stronie serwera
logi.txt (19,9 KB)

A i zapomniałem dodać ,że serwer OVPN stoi na maszynie virtualnej ( VirtualBox ) i wszystko jest ok według mnie . Karta sieciowa jest w trybie bridge czyli tak jakby istnieje w mojej sieci domowej jako maszyna oraz ma przypisany adres po MACu z puli DHCP.


(sadaj72) #10

Tue Oct 10 17:30:43 2017 us=386171 TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address already in use

Tue Oct 10 17:30:43 2017 us=386175 Exiting due to fatal error
Tue Oct 10 17:30:43 2017 us=386183 Closing TUN/TAP interface

Ja tam się nie znam, bo tego programu nie używam, ale chyba żaden program nie wyświetla na dzień dobry komunikatu Exiting due to fatal error.

Nie masz tam jakiegoś konfliktu ip czy coś?


(maciej12203) #11

Właśnie nie . Też tak myślałem po sprawdzeniu logów ,ale posprawdzałem w razie co wszystkie adresy IP i jest ok . Serwery mają adresy wykluczone z puli DHCP i przypisane po MACu.
A zresztą ta konfiguracja działała dla połączenia po lokalnym IP w przeciwnym wypadku wogóle nie byłoby żadnego połączenia po stronie lokalnej także chyba żadnego konfliktu nie ma . Problem dopiero przy połączeniu zewnętrznym .

Dla pewności jeszcze raz przeinstalowałem serwer OVPN. Lecz w logach nawet bez uruchamiania jakiegokolwiek klienta pojawia się ten sam błąd co przedtem, jakby już wywalało błędy odrazu po czystej/świeżej instalacji.


(roobal) #12
Tue Oct 10 17:49:43 2017 us=457909 NOTE: FlushIpNetTable failed on interface [5] {2F8E61FF-A294-404C-8910-6017527DAA26} (status=5) : Odmowa dostêpu.  
Tue Oct 10 17:49:43 2017 us=468743 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Oct 10 17:49:43 2017 us=468743 Blocking outside DNS
Tue Oct 10 17:49:43 2017 us=469685 Block_DNS: WFP engine opened
Tue Oct 10 17:49:43 2017 us=470667 Error in add_block_dns_filters(): add_sublayer: failed to add persistent sublayer : Odmowa dostêpu.   [status=0x5]
Tue Oct 10 17:49:43 2017 us=470667 Blocking DNS failed!
Tue Oct 10 17:49:43 2017 us=470667 Exiting due to fatal error

Wygląda na to, że Windows nie może utworzyć interfejsu. Uruchamiasz OVPN jako administrator?

Zaś ten błąd.

Tue Oct 10 17:30:43 2017 us=386171 TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address already in use

Tue Oct 10 17:30:43 2017 us=386175 Exiting due to fatal error
Tue Oct 10 17:30:43 2017 us=386183 Closing TUN/TAP interface

Że już masz uruchomioną jedną instancję OVPN. Dzieje się tak, jeśli OVPN uruchamia się automatycznie, a Ty uruchamiasz z palca.


(maciej12203) #13

Tak wszystko było uruchamiane i instalowane z prawami administratora to także ta opcja odpada . Czyli w sumie logi nie pokazują niczego złego tak na dobre patrząc . Zastanawia mnie to że skoro Windows nie chciał utworzyć interfejsu to jak lokalnie normalnie połączenie zostało nawiązane. Dziwne ,że na każdym kliencie wywala taki sam komunikat a wszystko instalowane i odpalane z prawami administratora . Może tak jak mówicie OVPN gryzie się z moim NATem i może by zastąpić go innym bezpieczenym rodzajem VPN . Jeszcze jakąś pomoc po obejrzeniu logów ? Może wina nie leży po stronie serwera jednak bo nie pokazuje w logach żadnych komunikatów co do łączenia się do serwera klienta.

Niżej potwierdzenie ,że lokalnie jest wszystko ok.

Później gdy zmienie z mojego lokalnego IP na adres publiczny w konfiguracji pojawia isę ten sam problem . Hosty nadal nie mogą się podłączyć . Pingują ten adres publiczny ,lecz dostać się do środka nie mogą :confused:


(roobal) #14

Każdy VPN będzie sprawiał problemy za NATem. VPNy stawia się na routerach brzegowych, firewallach, które mają publiczne IP i nie są za NATem.

Na tym zrzucie łączysz się z Linuksa. Pokaż logi z Linuksa, gdy łączysz się spoza sieci na publiczne IP.


(bachus) #15

Pokaż z ciekawości konfig.


(maciej12203) #16

Podsyłam poniżej połączenie gdy łączę się spoza sieci na publiczne IP. ( Muszę wysłać konfigurację w osobnym poście ,ponieważ nie mam takiej możliwości aby umieścić te rzeczy w jednym poście )


(maciej12203) #17

Poniżej umieszczam konfigurację client.ovpn - plik którym podłączam się do serwera. ( Załączone certyfikaty i klucz zostały ucięte ,ponieważ uważam je za zbędne w tej konfiguracji akurat )


(maciej12203) #18

Poniżej umieszczam konfigurację z głównego pliku serwera OVPN czyli server.conf


(bachus) #19

A na jakim IP jest router?


(maciej12203) #20

192.168.100.1 - adres interfejsu po stronie lokalnej ( adres routera )
109.173.200.210 - adres interfejsu po stronie zewnętrznej ( publiczny adres IP ) . Klient z zewnątrz jest wstanie spingować ten adres.