DNS Cache – cóż to za „zwierz”? :)

14 stycznia 2016 at 19:35

W ostatnim czasie kilka razy miałem okazję rozwiązywać problemy (lub brać udział w konsultacjach) związanych bezpośrednio lub pośrednio z rozwiązywaniem nazw. Mechanizmy związane z rozwiązywaniem nazw (m.in. DNS) wydaj się być proste i przejrzyste, jednak okazuje się, że często panują „miejskie legendy” i ogromne kłopoty z namierzeniem źródeł niepoprawnego/nieoczekiwanego działania usług. Słowem wstępu rozwińmy kilka definicji, żeby uniknąć niedomówień i wątpliwości: DNS (ang. Domain Name System) – System nazw domenowych lub jak kto woli system rozwiązywania nazw. Strefa wyszukiwania do przodu (ang. Forward Lookup Zone) –  strefa DNS, która służy do rozwiązywania nazw DNS typu: mkrzanowicz.it na adresy IP: 185.38.248.202Strefa wyszukiwania do tyłu (ang. Reverse Lookup Zone) – strefa DNS, która służy do rozwiązywania adresów IP na nazwy DNS. I tutaj uwaga, w zależności od tego czy mamy zarejestrowane rekordy PTR, czy nie (oraz ile mamy ich zarejestrowanych dla podanego adresu IP) wyniki mogą być nieoczekiwane. Posłużmy się przykładem mojego bloga: Chcieliśmy się dowiedzieć co kryje się pod adresem IP: 185.38.248.202 i oczekiwaliśmy, że zwróci odpowiedź mkrzanowicz.it a zwrócił… nazwę serwera hostingującego… W moim przypadku nie ma z tym problemu – na pytanie, czy tak ma wyglądać Wasz wewnętrzny DNS musicie odpowiedzieć sobie sami, aczkolwiek cytując klasyka „nie wydaje mnie […]

Interpreter/Parser logów NPS(RADIUS)

28 października 2015 at 22:38

Kontynuując wątek rozpoczęty w poprzednik wpisie (http://mkrzanowicz.pl/?p=485) pozostajemy w tematyce sieci komputerowych, VLANów, 802.1x, RADIUS’a, NPS’a… We wcześniejszym wątku opisałem krótko zmagania z dziwnym przypadkiem użytkownika nieobsługiwanego poprawnie przez polityki sieciowe na serwerze MS NPS (Network Policy Server). Metoda dojścia do rozwiązania była dosyć partyzancka, bo polegała na porównywaniu wszystkich parametrów kont użytkownika, któremu wszystko działało poprawnie oraz tego, którego dotyczył problem. Oczywiście najważniejsze że udało się rozwiązać problem, jednak mimo wszystko istotny jest czas rozwiązywania podobnych przypadków. To skłoniło mnie do głębszego sięgnięcia w dokumentację oraz zapisy standardów. Okazuje się że logi NPS/IAS/RADIUS w wydaniu Microsoftu są bardzo ciekawie skomponowane. W relatywnie niewielkim rozmiarze zawartych jest ogrom informacji potrzebnych do weryfikacji ewentualnych problemów, raportowania, statystyk etc. Chociaż będąc uczciwym trzeba przyznać że pierwszy kontakt z tą formą logowania informacji powoduje reakcję typu „WTF?” albo skłania do domysłów o co chodzi. Potem następuje przegrzebywanie dokumentacji w poszukiwaniu informacji i manualne rozszyfrowywanie poszczególnych pozycji… Aż w końcu rodzi się myśl czy nie można tego zrobić lepiej, szybciej, automatycznie? Zacznijmy od składni takiego loga. Przykładowy wpis wygląda tak: „10.10.10.4,anonymous,10/12/2015,13:06:10,IAS,RADIUS1,6,2,12,1500,30,50-50-A8-D3-C1-EE,38,5C-97-0E-DD-F2-55,61,15,5,50130,87,GigabitEthernet1/4,4,10.10.10.4,4108,10.10.10.4,4116,9,4128,switch1,4154,NAP 802.1X (Wired),4155,1,4129,MKrzanowicz\anonymous,4130,MKrzanowicz\anonymous,4132,,25,311 1 10.10.10.11 09/11/2015 06:09:17 39763,4127,5,4136,1,4142,0” Trochę adresów IP, trochę adresów MAC, trochę kont domenowych, data i godzina i „jakieś cyferki” Po zagłębieniu się […]

Brak dostępu do VLAN’ów z wykorzystaniem serwera RADIUS/NPS

26 października 2015 at 10:45

Podczas wdrażania rozwiązania dostarczającego funkcjonalności 802.1x, czyli dynamicznego przełączania VLAN’ów w zależności od zdefiniowanych reguł dotyczących użytkownika domenowego Active Directory, gdzie rolę serwera RADIUS pełni Microsoftowe rozwiązanie NPS (Network Policy Server) w przypadku wybranej grupy użytkowników pojawiał się problem. Polegał on na tym, że w logach IAS widoczne były eventy świadczące o prawidłowym żądaniu/przydzielaniu VLAN,a  mimo to stacja lądowała w VLANie Guestowym ze statusem portu (no-response, timeout, not-autorized …). Wyeliminowane zostały wszystkie zmienne takie jaki różnic a w konfiguracji switcha, różnice w polisach sieciowych, inne gniazdka sieciowe, kable, stacja robocza… pozostał tylko i wyłącznie użytkownik. Ale co z nim było nie tak? Dlaczego inne osoby logujące się na tej stacji otrzymywały poprawne VLAN’y? Jedyną „zmienną” pozostała konfiguracja konta użytkownika. Pozostało więc zrzucanie i porównywanie wszystkich atrybutów konta użytkownika, któremu rozwiązanie 802.1x działa prawidłowo oraz takiego dotkniętego problemem. Po kilku minutach analizy znaleziony został winny. Użytkownik miał ustawiony na swoim koncie atrybut: msNPAllowDialin = $false Niektórzy zastanawiają się co uprawnienie „Allow Dial-In” ma wspólnego z niedziałającym dostępem 802,.1x? Wystarczy rozszyfrować nazwę serwera RADIUS = „Remote Authentication Dial In User Service” i wszystko staje się jasne, chociaż przyczyna była dosyć niejasna… Metoda dojścia do rozwiązania dosyć mocno „partyzancka”, ale ważne że skuteczna. […]

MTU 1504 i wiszące sesje…

26 stycznia 2015 at 09:58

Dosyć nietypowy problem na stacji jednego z użytkowników: Połączenie z domeną Active Directory działa prawidłowo, jest dostęp do zasobów sieciowych, poczty elektronicznej i całego pozostałego BackEndu, jednak pojawił się problem przy połączeniu z bazą danych. Połączenie było nawiązywane prawidłowo, jednak po pewnym czasie było zawieszane z nieokreślonej przyczyny.  Przy wspólnej analizie z zespołem sieciowców udało się ustalić przyczynę takiego stanu rzeczy – była nią nieprawidłowa wartość parametru MTU na interfejsie sieciowym, który był wyższy niż MTU na switchu, do którego była wpięta stacja. Z tego też względu żaden z dostępnych mechanizmów wbudowanych w system (jak PMTU, czy fragmentacja pakietów) nie był w stanie obsłużyć tego przypadku, bo pakiety były dropowane już na warstwie 2, bez informacji zwrotnej…. Skąd się wzięła rozbieżność w konfiguracji MTU? Windows domyślnie ustawia wartość 1500, natomiast w tym wypadku ustawione było 1504. Po dłuższym googlowaniu udało się ustalić, że HP wypuścił „trefną” serię sterowników z ustawionym MTU na wartość 1504… Karty sieciowe, które były dotknięte tą przypadłością to m.in: HP NC382 HP NC532 HP Flex-10 10Gb 2-port 530FLB Niepoprawne sterowniki były wypuszczane w seriach od 7.4.x.y – dopiero serie 7.8.x.y mają poprawioną konfigurację MTU. OK – zlokalizowaliśmy przyczynę problemów – ale teraz czas na znalezienie globalnego […]

© Marcin Krzanowicz