Dzisiaj kolega ezaq podesłał mi dwie informacje: dobrą i złą. Dobra jest taka, że pula adresów IP dla Aero2 została ponownie powiększona, tym razem o nieco ponad 2000 adresów. Zła jest taka, że ponownie użytkownicy usługi bezpłatnej mają spory związany z tym problem: jeżeli otrzymają adres IP z nowej puli, nie mogą normalnie korzystać z dostępu do Internetu: modem normalnie nawiąże połączenie, ale nic więcej nie działa. Jeżeli jednak trafią na stary adres IP – wszystko działa poprawnie. Mam nadzieję, że problem zostanie szybko rozwiązany.

Opis nowej puli IP, szczegółowe wyjaśnienie problemu oraz rozwiązanie tymczasowe można znaleźć w dalszej części artykułu.

Nowa pula adresów IP…

Od jakiegoś czasu pojawiały się tu i tam raporty o problemach niektórych użytkowników z uzyskaniem dostępu do Internetu ze względu na komunikat o konflikcie adresów IP. Nie mam pewności, czy jest to objaw wyczerpywania się dotychczasowej puli około 3500 adresów, jakie mieliśmy do dyspozycji, czy też efekt innych problemów lokalnych, ale faktem jest, że oto operator postanowił dodać nową pulę:

inetnum:        37.209.128.0 - 37.209.135.255
netname:        AERO2-FREE
descr:          AERO2 Mobile Broadband Services
country:        PL

Daje nam to nieco ponad 2000 dodatkowych adresów IP, czyli łącznie z przydzielonymi wcześniej adresami mamy teraz ponad 5500 adresów IP, a więc maksymalnie tyle użytkowników BDI może korzystać z dostępu do sieci jednocześnie.

…i problemy z nową pulą

Jednak osoby, które po połączeniu otrzymają adres IP z powyższej puli raportują, że nie są w stanie korzystać z sieci – nie działają żadne strony internetowe i większość innych usług, ale działa między innymi Skype. Oto wyniki mojego śledztwa technicznego.

Po pierwsze postarałem się uzyskać adres z nowej puli, co potwierdziłem poleceniem ipconfig w systemie Windows:

   Sufiks DNS konkretnego połączenia :
   Opis. . . . . . . . . . . . . . . : PL-Aero2
   Adres fizyczny. . . . . . . . . . :
   DHCP włączone . . . . . . . . . . : Nie
   Autokonfiguracja włączona . . . . : Tak
   Adres IPv4. . . . . . . . . . . . . : 37.209.130.42(Preferowane)
   Maska podsieci. . . . . . . . . . : 255.255.255.255
   Brama domyślna. . . . . . . . . . : 0.0.0.0
   Serwery DNS . . . . . . . . . . . : 193.41.112.14
                                       193.41.112.18

Teraz wykonałem standardowy test ping:

C:\>ping jdtech.pl
Żądanie polecenia ping nie może znaleźć hosta jdtech.pl. Sprawdź nazwę i ponów próbę.

No to wiemy, faktycznie coś jest nie tak. Sprawdźmy, czy w ogóle zachodzi jakiś ruch sieciowy:

C:\>ping 87.98.219.28

Badanie 87.98.219.28 z 32 bajtami danych:
Odpowiedź z 87.98.219.28: bajtów=32 czas=105ms TTL=56
Odpowiedź z 87.98.219.28: bajtów=32 czas=114ms TTL=56
Odpowiedź z 87.98.219.28: bajtów=32 czas=93ms TTL=56
Odpowiedź z 87.98.219.28: bajtów=32 czas=112ms TTL=56

Statystyka badania ping dla 87.98.219.28:   
Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0
             (0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 93 ms, Maksimum = 114 ms, Czas średni = 106 ms

A jednak, ruch w sieci działa poprawnie. Spróbujmy więc zobaczyć, o co chodzi z serwerem DNS – bo adresy tych serwerów zostały prawidłowo przydzielone.

C:\>nslookup jdtech.pl
Serwer:  oreius.sferia.net
Address:  193.41.112.14

*** oreius.sferia.net nie może odnaleźć jdtech.pl: Query refused

No to mamy winnego: serwer DNS aktywnie odmawia nam pomocy – uznał nas za obcych w swojej sieci i nie pozwala zadać pytania.  Sprawdźmy, czy problem nie leży w ograniczeniach w ruchu sieciowym:

C:\>nslookup jdtech.pl 8.8.8.8
Serwer:  google-public-dns-a.google.com
Address:  8.8.8.8

Nieautorytatywna odpowiedź:
Nazwa:   jdtech.pl
Address:  87.98.219.28

Publiczny serwer DNS firmy Google odpowiedział bez zająknięcia. Czyli wiemy wszystko.

Wyjaśnienie problemu

Jak widzimy operator dodał na potrzeby użytkowników BDI nową pulę adresów. Jednak ktoś zapomniał powiedzieć o tym serwerom DNS należącym do operatora (oreius.sferia.net – 193.41.112.14 oraz jadis.sferia.net – 193.41.112.18). Efektem tego jest aktywna odmowa obsługi zapytań do serwerów DNS z nowych adresów IP, a tym samym problemy z normalnym korzystaniem  dostępu do Internetu. Problem ten jednak nie dotyczy usług, które nie potrzebują serwerów DNS (a więc zamiany nazw takich, jak jdtech.pl na ciąg liczb takich, jak 87.98.219.28), na przykład Skype.

Rozwiązania tymczasowe

Jak sobie poradzić z tym problemem, zanim operator wprowadzi odpowiednie poprawki w konfiguracji serwerów DNS? Możliwości są co najmniej dwie. Najprostsza to próba rozłączenia i ponownego połączenia, aż otrzymamy adres IP ze starej puli (przypomnę – zaczynający się od liczby 78.*).

Mam także znacznie lepsze rozwiązanie: możemy po prostu zrezygnować z adresów DNS dostarczanych przez operatora i ustawić własne. W zależności od posiadanego systemu operacyjnego musimy wyświetlić konfigurację IP połączenia z Internetem przez Aero2. Ustawienia połączenia znajdziemy na liście połączeń sieciowych w Centrum sieci i udostępniania w Windows 7 lub we właściwościach otoczenia sieciowego w Windows XP. Po wyświetleniu właściwości połączenia sieciowego związanego z Aero2 musimy znaleźć konfigurację protokołu internetowego IPv4, włączyć opcję Użyj następujących adresów serwerów DNS i wpisać adresy 8.8.8.8 oraz 8.8.4.4 (są to serwery należące do firmy Google). W Windows 7 okno konfiguracji protokołu IP powinno wyglądać następująco:

Ustawienia serwerów DNS

Po tej zmianie staniemy się niezależni od serwerów DNS operatora oraz ich błędnej konfiguracji i wszytko wróci do normy i będziemy mogli normalnie korzystać z sieci.

***

Mam nadzieję, że z jednej strony problem zostanie rozwiązany szybko, a z drugiej strony takie problemy techniczne będą się zdarzały jednak jak najrzadziej.

Podziękowania: ezaq za przesłanie informacji i wstępnej diagnozy

1. Aero2 – nowa pula adresów IP
2. Aero2 – nowa pula adresów IP – listopad 2013
3. Aero2 – nowa pula adresów IP – czerwiec 2013
4. Aero2 – problemy z połączeniem – znowu brakuje adresów IP
5. Aero2 – 4000 nowych adresów IP dla Darmowego Internetu