Zablokowane przedziały portów

0

Pracowałem sobie nad aplikacją już dobry miesiąc, i dzisiaj rano docker nie mógł postawić kontenerów które miały słuchać na pewnych portach.

Chwila debugowania, i znalazłem takie cóś:

PS C:\Users\Riddle> netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
      5165        5264
      5357        5357
      5358        5457
      5458        5557
      5558        5657
      5658        5757
      5758        5857
     50000       50059     *

* - Administered port exclusions.

Okazało się (a przynajmniej tak by się wydawało), że z jakiegoś powodu niektóre range portów są bloknięte. Pierwszy raz odpaliłem to excludedportrange, więc nie mogę powiedzieć czy dopiero teraz tak jest czy było wcześniej; ale domyślam się że ponieważ używałem apki np na porcie 5435 przez miesiąć, i dopiero dzisiaj przestało działać, to chyba to znak że jednak coś mi dodało tego range'a.

Nie instalowałem żadnych nowych aplikacji, i nie zmieniałem ustawień, więc pozostaje pomysł że te porty są dodane przez update windowsa?

Ma ktoś jakiś pomysł skąd się wzięły te range, oraz czy coś się złego stanie jak je "odbloknę"?

0

Wygląda na problem podobny do tego tutaj , używasz albo masz włączone hyper-v?
https://github.com/docker/for-win/issues/3171
Ewentualnie czasami upgrade windowsa podobno stwarza takie problemy (są w komentach jakieś rozwiązania)
https://github.com/microsoft/WSL/issues/5306

tu teoretyczne rozwiązanie przez wyłączenie hyper-v , rezerwację portu aby hyper-v nie przypisało go sobie
https://github.com/docker/for-win/issues/3171#issuecomment-459205576

0

Umiem to naprawić.

Pytanie polega - jak ustalić co dodało tę range?

0

Wydaje mi się, że nadal to problem hyper-v (przy docker for windows chyba trzeba go uruchomić) lub aktualizacji windowsa \ gdzieś widziałem, że czasami system blokuje ze względu na ochronę przed wirusami, ale tę opcję raczej bym tutaj wykluczył.
Chodzi raczej o samą konfigurację tego jakie porty mogą być dynamicznie przez system zajmowane i przeważnie przy każdym restarcie zajmowana pula się zmienia.
Jak uruchomisz komendę

netsh int ipv4 show dynamicport tcp

zobaczysz swój zakres z jakich dynamicznych portów może korzystać windows. Domyślnie zaczynają się od 1024 lub 1025 , ale powinieneś ustawić start port na zdecydowanie większy bo sporo użytecznych aplikacji działa na portach poniżej 10k .
Sam mam ustawione taką komendą

netsh int ipv4 set dynamic tcp start=49152 num=16384

Nie jestem pewien tylko czy nie trzeba wyłączyć hyper-v przed kombinowaniem z tym.

Co o tym myślisz?

0
CPTBombax napisał(a):

Wydaje mi się, że nadal to problem hyper-v (przy docker for windows chyba trzeba go uruchomić) lub aktualizacji windowsa \ gdzieś widziałem, że czasami system blokuje ze względu na ochronę przed wirusami, ale tę opcję raczej bym tutaj wykluczył.
Chodzi raczej o samą konfigurację tego jakie porty mogą być dynamicznie przez system zajmowane i przeważnie przy każdym restarcie zajmowana pula się zmienia.
Jak uruchomisz komendę

netsh int ipv4 show dynamicport tcp

zobaczysz swój zakres z jakich dynamicznych portów może korzystać windows. Domyślnie zaczynają się od 1024 lub 1025 , ale powinieneś ustawić start port na zdecydowanie większy bo sporo użytecznych aplikacji działa na portach poniżej 10k .
Sam mam ustawione taką komendą

netsh int ipv4 set dynamic tcp start=49152 num=16384

Nie jestem pewien tylko czy nie trzeba wyłączyć hyper-v przed kombinowaniem z tym.

Co o tym myślisz?

Myślę, że nie interesuje mnie co ci Ci się wydaje, tylko to w jaki sposób sprawdzić co faktycznie dodało te range.

Wierz lub nie, ale po wpisaniu excludedportrange ip4v w google, 4 pierwsze linki dotyczą hyper-v, więc wpadłem na ten pomysł. Chciałbym się jednak upewnić co je dodało, stąd pytanie jak to sprawdzić.

0

Taki trochę rzut na taśmę - netstat -o daje PID blokujące porty. IMO to jest chyba najsensowniejszy punkt zaczepienia, bo nie spodziewam się, żeby Windows trzymał gdzieś logi w stylu "ten update spowoduje, że apka X zacznie blokować porty o numerach 10000, 10001".

0
wartek01 napisał(a):

Taki trochę rzut na taśmę - netstat -o daje PID blokujące porty. IMO to jest chyba najsensowniejszy punkt zaczepienia, bo nie spodziewam się, żeby Windows trzymał gdzieś logi w stylu "ten update spowoduje, że apka X zacznie blokować porty o numerach 10000, 10001".

Zablokowane range portów nie są tam pokazane. netstat -o pokazuje otwarte porty, na których coś nasłuchuje. Na portach z wątku nic nie nasłuchuje, ponieważ są excluded.

0

Dokładnie znalezienie tego co włączyło te porty może być trudne, ale można to próbować robić drogą dedukcji.
Włączyłem na chwilę na komputerze hyper-v i takie range portów mi się dodały (Mam ustawione dynamiczny range z poprzednich postów więc są wysokie).
Jest podobieństwo w samych zakresach do tych Twoich (po 99) więc upieram się dalej przy tej funkcji bo po wyłączeniu takie zakresy znikły. Z resztą sam możesz to sprawdzić u siebie.

Po włączeniu hyper-v

porty z hyper-v.png
Po wyłączeniu funkcji hyper-v w sytemie

HyperVPoWylaczeniu.png

0
CPTBombax napisał(a):

Dokładnie znalezienie tego co włączyło te porty może być trudne, ale można to próbować robić drogą dedukcji.
Włączyłem na chwilę na komputerze hyper-v i takie range portów mi się dodały (Mam ustawione dynamiczny range z poprzednich postów więc są wysokie).
Jest podobieństwo w samych zakresach do tych Twoich (po 99) więc upieram się dalej przy tej funkcji bo po wyłączeniu takie zakresy znikły. Z resztą sam możesz to sprawdzić u siebie.

Metodą "spróbuj usunąć, zobaczymy co się stanie" to ja raczej dziękuje.

@CPTBombax krótka piłka - masz coś do dodania w tej sprawie, czy masz plan tylko rzucać pomysły w stylu "zobacz, może zadziała"? Bo jeśli tak, to dziękuję za udział w odpowiedzi, ale daj innym się wypowiedzieć.

1 użytkowników online, w tym zalogowanych: 0, gości: 1