Latest Entries »

Jeśli stawia się własny serwer DNS do obsługi jakiejś domeny, jednym z podstawowych narzędzi troubleshootingu i oceny działania DNS jest narzędzie nslookup. Jest to jedno z poleceń – podprogramów, które mają własne menu. Nie tylko możemy sprawdzić jakiś serwer (polecenie nslookup google.com):

image

Ale możemy “wejść” do nslookup:

image

Co widać na powyższych screenach?

Po pierwsze – serwer DNS, którego odpytujemy. dla mniej jest to jeden z serwerów DNS Politechniki Rzeszowskiej – ns1.prz.edu.pl, znajdujący się pod adresem 62.93.32.67

Po drugie wpisując nslookup domena.com otrzymujemy listę serwerów, które w internecie znane są jako domena.com. W przypadku microsoft.com są to dwa adresy IP.

Co ciekawe, adresy te są odpowiedzią ze źródła nieautorytatywnego (non-authoritative answer):

image

Tak samo jest z google.com:

image

Co to oznacza?

Początkowo, skanując “swój” serwer DNS (na przykład gdybym miał domenę kicekpicek.com) można się przestraszyć, czemu moja domena nie ma odpowiedzi authoritative a tylko non-authoritative. I dlaczego korzystając z serwera DNS Politechniki, PRz ma odpowiedź authoritative a URz non-authoritative?

Tu odpowiedzi po ustawieniu dodatkowego skanowania wpisów SOA (set type=SOA):

image

Jak widać, nad prz.edu.pl nie pojawia się dopisek Non-authoritative answer:

Serwer autorytatywny to ten, który odpowiada o danym adresie, będąc jego prawdziwym Name Server (NS). Tak po naszemu, to serwer prz.edu.pl odpowiada jako serwer autorytatywny, jeśli to jego pytamy o jakiś adres w tej domenie, np. portal.prz.edu.pl i to ten serwer wskaże nam IP. DNS-y jednak, aby szybciej działać, dużo nazw trzymają w swoim cache. I tak naprawdę tylko pierwsze pytanie będzie authoritative, każde kolejne pytanie o prz.edu.pl będzie już wyciągane z cache najbliższego nam serwera DNS. Ale serwer ten wie, że nie ma pewności, czy “coś dalej “ się nie zmieniło – stąd też odpowiada, że jest non-authoritative, jeśli chodzi o rozwiązanie tych nazw.

We wpisie SOA widać też, przez ile będzie trzymał informację przed jej wygaśnięciem, po ilu godzinach od pierwszego skeszowania sprawdzi ponownie i co ile będzie sprawdzał później w wyniku niepowodzenia oraz jakie są serwery nazw danej domeny.

 

Źródło: http://tycoontalk.freelancer.com/computer-forum/211148-non-authoritative-answer.html

oraz własne doświadczenia Uśmiech

Opisałem to po trochę na WSS, trochę na forum WSS też o tym pisałem, ale chciałbym dorzucić do tego coś więcej niż sam opis…

Na początek – po co?

Przekierowanie portu to “uwidocznienie” jakiegoś kompa za Firewallem lub routerem (NAT-ującym a właściwie PAT-ującym) dla sieci zawnętrznej – standarowo jeśli jesteś za Firewallem lub routerem jesteś widoczny w internecie pod ip routera a nie pod adresem posiadanym w sieci lokalnej.

NAT – PAT

Te dwa pojęcia używa się zamiennie, jednak różnica jest dość znaczna. Dość powiedzieć, że mając typowy NAT prawie wcale nam przekierowania portów nie trzeba.

NAT, czyli Network Address Translation, to tłumaczenie przez router adresów sieci wewnętrznej na adresy sieci zewnętrznej. W teorii służyło to do zorganizowania sobie sieci, kiedy od ISP (dostawcy neta) dostawaliśmy kilka – powiedzmy 6 (żeby było na okrągło z podsieci /29) – adresów IP i mieliśmy wewnątrz sieci 10 komputerów. Na zewnątrz dostawaliśmy adresy IP np. 52.68.y.1-6 a my w sieci stosowaliśmy sobie adresację prywatną 192.168.2.10-20. Korzystając z NAT-a, tylko 6 z naszych 10 komputerów mogło korzystać z sieci na zewnątrz – router “przepisywał” dla danego adresu wewnątrz adres zewnętrzny, na przykład

192.168.2.10 – Router – 52.68.x.1

192.168.2.12 – Router – 52.68.x.2

i tak dalej. Router można było skonfigurować statycznie (wtedy pozostałe 4 komputery w naszej sieci pozostawały lokalnymi) albo dynamicznie – “kto pierwszy ten lepszy” – wtedy pierwsze 6 komputerów “zajmowało” NAT i pozostałe mogły działać tylko lokalnie, dopóki port się nie skończył.

PAT – Port Address Translation – to coś, co jest powszechne i trafiło pod strzechy z nazwą…NAT. I mimo, że to coś innego, NAT kojarzony jest z działaniem PAT a o PAT się zapomina :)

PAT daje nam możliwość ukrycia dużej liczby komputerów za jednym zewnętrznym adresem IP. Router zapisuje sobie, z jakiego adresu IP i portu przyszedł pakiet, otwiera u siebie pseudolosowo wybrany port i wysyła pakiet dalej jako źródło pokazując swój IP i wylosowany port. Odpowiedź na pakiet trafia na ten wylosowany port, router sprawdza, komu go przypisał i tam odsyła pakiet.

Czyli w routerze zostaje nam tabelka:

192.168.2.10:909 – ROUTER – 52.68.x.1:5455

192.168.2.10:919 – ROUTER – 52.68.x.1:5855

192.168.2.13:850 – ROUTER – 52.68.x.1:1555

192.168.2.13:6532 – ROUTER – 52.68.x.1:7878

Dzięki temu router wie, że jeśli z internetu dostanie pakiet skierowany na adres 52.68.x.1:5855, ma go przesłać dalej na wewnętrzny adres 192.168.2.10 na port 919.

Jak z tego skorzystać?

Co nam to daje? Możemy na przykład opublikować kilka, kilkanaście, a nawet kilkadziesiąt stron internetowych na jednym IP. Musimy tylko ustawić statyczne przekierowania portów. Standardowo ruch HTTP to ruch na porcie 80, ale możemy przecież “wystawić” przez router wskazanie:

192.168.2.10:80 – ROUTER – 52.68.x.1:700

192.168.2.11:80 – ROUTER – 52.68.x.1:701

192.168.2.12:80 – ROUTER – 52.68.x.1:702

192.168.2.13:80 – ROUTER – 52.68.x.1:703

Teraz osoba, która wpisze w przeglądarce adres http://52.68.x.1/ nie znajdzie strony, ale jeśli wpisze http://52.68.x.1:700/ trafi na stronę hostowaną przez 192.168.2.10, jeśli :702, to na stronę hostowaną przez .2.12 i tak dalej. Tak samo można wykonać z pulpitem zdalnym, na przykład:

192.168.2.11:3389 – ROUTER – 52.68.x.1:7001

Osoba, która spróbuje połączyć się pulpitem zdalnym na adres 52.68.x.1:7001, połączy się do komputera .2.11 :)

Windows Server 200x

Ok, wiemy, z czym to się je. To teraz szybka lekcja włączania przekierowania portów w usłudze RRAS.

Wychodzę z założenia, że RRAS każdy włączyć potrafi, ale może to opiszę “in the future”.

Włączamy przystawkę Routing and Remote Access i dochodzimy do NAT (heh…), jak na rysunku:

image

Klikamy prawym klawiszem na interfejs obsługujący nasze połączenie z internetem (u mnie jest to “Swiat”):

image

Wybieramy Properties (Właściwości) i przechodzimy na ostatnią zakładkę:

image

Znajduje się tu lista prekonfigurowanych, ale wyłączonych mapowań portów. Jeśli na któryś z gotowców klikniemy, wyświetli nam się okno:

image

Nie daje nam to jednak możliwości konfiguracji portu zewnętrznego – możemy tylko wpisać adres wewnętrzny. Jednak jeśli damy Add otrzymamy okno:

image

Gdzie oprócz nazwy można skonfigurować protokół – UDP lub TCP a także port przychodzący i wychodzący. Ja ustawiłem przekierowanie tak, że ktoś wchodząc na http://mojip:6000/ zobaczy stronę, która udostępniona jest na komputerze o adresie 10.1.1.12.

Tyle. To już działa!

A jeśli chcę to osiągnąć z linii poleceń?

Ok, wiem, że ludzie przenoszą się z linuxa i mówią “tam mam wpisy w IPTABLES i wszystko widzę”… W Windows z linii poleceń… można to zrobić łatwiej i czytelniej!

Zamiast wpisu:

iptables -t nat -A PREROUTING -i eth1 -s 83.xx.xx.142 -p udp -m udp –dport 1567 -j DNAT –to-destination 10.0.0.205:1521

(gdzie już się pogubiłem ;) ) wystarczy, że w cmd z poziomem admina wpiszę:

netsh routing ip nat add portmapping Swiat tcp 0.0.0.0 5555 192.168.0.2 3389

Teraz… co jest co?

netsh routing ip – pokazuje, że będę konfigurował routing ipv4 (ip=ipv4) przy użyciu netsh – narzędzia do konfiguracji sieci

nat – to chyba jasne – precyzuję, że będzie to dotyczyć NAT

add portmapping – dodaję mapowanie/przekierowanie portów

Swiat – nazwa mojego interfejsu, traktowanego jako “zewnętrzny” przy mapowaniu

tcp – protokół

0.0.0.0 – adres z zewnątrz, jakiego ma to dotyczyć. Quad-zero oznacza tu “dowolny adres”

5555 – port zewnętrzny

192.168.0.2 – IP wewnątrz sieci

3389 – port urządzenia, który ma być mapowany

Dzięki temu, z jakiegokolwiek adresu ktoś będzie chciał się podłączyć pulpitem zdalnym na mojip:5555, dostanie się do komputera 192.168.0.2.

Przy takiej konfiguracji w zakładce "Services and Ports" nie będzie nazwy (jak Remote Desktop czy Visual-PS), tylko "Custom Service 1" itp.

 

Źródła:

Kurs Cisco + własne laby + TechNet

Po przestoju

W końcu planuję wrócić.

Zaangażowałem się dość mocno w prace na WSS.pl, także w jego przyszłej, nowej odsłonie WSS.pl (news).

Trochę zmieniła się moja sytuacja życiowa – pracuję, równocześnie studiując drugi kierunek (mgr inż. elektroniki i telekomunikacji już jest ;), jestem w redakcji WSS.pl, przestałem być Student Partnerem jako liderem Grupy, zacząłem być Student Consultantem – liderem grupy Student Partnerów.

Nauczyłem się ostatnio sporo, wiele rzeczy zdążyłem przetestować (w końcu mam gdzie ;) i tak dalej. Mam jednak trochę treści, którą będę chciał się podzielić a jest bardziej blogowa niż WSS-owa, więc… chyba uda się wrócić ;)

Wiem, że zanim ktoś to przeczyta, minie mnóstwo czasu, ale przynajmniej sam sobie zorganizuję technologiczny pamiętnik :D

W programie DreamSpark znów udostępniono możliwość wygenerowania sobie vouchera na egzamin Microsoft oznaczony 72-xxx. Są to egzaminy studenckie. Warto wygenerować sobie voucher jak najszybciej, bo jest ich ograniczona liczba, bodajże 250 tys. na świat. Vouchery są ważne do 30 czerwca br., więc czas na naukę jest :)
Kto nie ma dostępu do DreamSpark, może się zwrócić do pledu@microsoft.com – ktoś tam powinien odpowiedzieć.
Co ważne – voucher pozwala na zdawanie egzaminu ZA DARMO, ale W MOMENCIE ZDAWANIA trzeba okazać ważną legitymację – nie ma sensu generować sobie klucz, kończąc teraz (luty-marzec) studia.

Informacja ta jest o tyle ciekawa i fajna, że akurat kilka dni wcześniej w ramach Koła Naukowego stwierdziliśmy, że będziemy się wspólnie przygotowywać do 70-642. Wszelkie informacje na http://kneiti.prz.edu.pl/
Spotkań będzie prawdopodobnie 15, planujemy skończyć cykl w czerwcu – akurat tak, żeby skorzystać z voucherów :)
Jeśli jest ktoś chętny na naukę do 70-642, zapraszamy na nasze spotkania – w środy od 18 na PRz, prawdopodobnie w laboratorium A-51