Co to jest plik sieci w systemie Windows. Co powinno znajdować się w pliku sieci

Dobrego czasu, drodzy czytelnicy. Wrzucam drugą część. Bieżący rozdział koncentruje się na Implementacja sieci w Linuksie(jak skonfigurować sieć w Linuksie, jak diagnozować sieć w Linuksie i jak dbać o podsystem sieciowy w Linuksie).

Konfigurowanie protokołu TCP/IP w systemie Linux dla sieci Ethernet

Aby pracować z protokołami sieciowymi TCP / IP w systemie Linux, wystarczy mieć tylko interfejs pętli zwrotnej, ale jeśli chcesz połączyć ze sobą hosty, potrzebujesz oczywiście interfejsu sieciowego, kanałów transmisji danych (na przykład skrętki), ewentualnie jakiegoś sprzętu sieciowego. Konieczne jest również zainstalowanie (itp.), zwykle dostarczane w formacie . Musi także mieć sieć (na przykład /etc/hosts) i obsługę sieci.

Ustawienia sieci

Zacznijmy rozumieć mechanizmy sieciowe Linuksa od ręcznej konfiguracji sieci, czyli od momentu kiedy adres IP Interfejs sieciowy statyczny. Tak więc podczas konfigurowania sieci należy wziąć pod uwagę i skonfigurować następujące parametry:

adres IP- jak już wspomniano w pierwszej części artykułu - jest to unikalny adres maszyny, w formacie czterech liczb dziesiętnych oddzielonych kropkami. Zwykle podczas pracy w lokalna sieć, wybrany z prywatnych zakresów, na przykład: 192.168.0.1

Maska podsieci- także 4 liczby dziesiętne, które określają, która część adresu odnosi się do adresu sieci/podsieci, a która do adresu hosta. Maska podsieci to liczba, która jest dodawana (w postaci binarnej) z adresem IP, aby dowiedzieć się, do której podsieci należy adres. Na przykład adres 192.168.0.2 z maską 255.255.255.0 należy do podsieci 192.168.0.

Adres podsieci- określana przez maskę podsieci. Jednocześnie nie ma podsieci dla interfejsów pętli zwrotnej.

Adres transmisji- adres używany do wysyłania pakietów rozgłoszeniowych, które będą odbierane przez wszystkie hosty w podsieci. Zwykle jest to adres podsieci o wartości hosta 255, czyli dla podsieci 192.168.0 rozgłoszenie będzie miało postać 192.168.0.255, podobnie dla podsieci 192.168 rozgłoszenie będzie miało postać 192.168.255.255. Nie ma adresu rozgłoszeniowego dla interfejsów pętli zwrotnej.

Adres IP bramy to adres maszyny będącej domyślną bramą do komunikacji ze światem zewnętrznym. Może istnieć wiele bram, jeśli komputer jest jednocześnie podłączony do wielu sieci. Adres bramy nie jest używany w sieciach izolowanych (nie podłączonych do sieci WAN), ponieważ sieci te nie mają gdzie wysyłać pakietów poza sieć, to samo dotyczy interfejsów pętli zwrotnej.

Adres IP serwera nazw (serwer DNS)- adres serwera konwertującego nazwy hostów na adresy IP. Zazwyczaj dostarczane przez dostawcę usług internetowych.

Pliki ustawień sieciowych systemu Linux (pliki konfiguracyjne)

Aby zrozumieć działanie sieci w systemie Linux, zdecydowanie radzę przeczytać artykuł „”. Ogólnie rzecz biorąc, cała praca Linuksa jest oparta na tym, co rodzi się, gdy system operacyjny uruchamia się i tworzy swoich potomków, którzy z kolei wykonują całą niezbędną pracę, niezależnie od tego, czy działa bash, czy demon. Tak, a cały rozruch Linuksa jest oparty na tym, co określa całą sekwencję uruchamiania małych narzędzi z różnymi parametrami, które są sekwencyjnie uruchamiane / zatrzymywane podczas uruchamiania / zatrzymywania systemu. Podsystem sieciowy Linux uruchamia się w ten sam sposób.

Każda dystrybucja Linuksa ma nieco inny mechanizm inicjalizacji sieci, ale myślę, że ogólny obraz po przeczytaniu będzie jasny. Jeśli spojrzysz na skrypty startowe podsystemu sieciowego niektórych Dystrybucja Linuksa, to jak skonfigurować konfigurację sieci za pomocą plików konfiguracyjnych stanie się mniej więcej jasne, na przykład w Debianie (weźmiemy tę dystrybucję jako podstawę), skrypt jest odpowiedzialny za inicjalizację sieci /etc/init.d/networking oglądając które:

Net-server:~#cat /etc/init.d/networking #!/bin/sh -e ### BEGIN INIT INFO # Udostępnia: networking # Required-Start: mountkernfs $local_fs # Required-Stop: $local_fs # Powinien -Start: ifupdown # Powinien-Stop: ifupdown # Domyślny-Start: S # Domyślny-Stop: 0 6 # Krótki opis: Podnieś interfejsy sieciowe. ### KOŃCOWA ŚCIEŻKA INFORMACJI POCZĄTKOWEJ="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" [ -x /sbin/ifup ] || wyjście 0 . /lib/lsb/init-functions process_options() ( [ -e /etc/network/options ] || return 0 log_warning_msg "/etc/network/options nadal istnieje i będzie IGNOROWANE! Przeczytaj README.Debian z netbase." ) check_network_file_systems() ( [ -e /proc/mounts ] || return 0 if [ -e /etc/iscsi/iscsi.initramfs ]; then log_warning_msg "brak dekonfiguracji interfejsów sieciowych: iSCSI root jest zamontowany." exit 0 fi exec 9<&0 < /proc/mounts while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network devices still mounted." exit 0 ;; esac case $FSTYPE in nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs) log_warning_msg "not deconfiguring network interfaces: network file systems still mounted." exit 0 ;; esac done exec 0<&9 9<&- } check_network_swap() { [ -e /proc/swaps ] || return 0 exec 9<&0 < /proc/swaps while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network swap still mounted." exit 0 ;; esac done exec 0<&9 9<&- } case "$1" in start) process_options log_action_begin_msg "Configuring network interfaces" if ifup -a; then log_action_end_msg $? else log_action_end_msg $? fi ;; stop) check_network_file_systems check_network_swap log_action_begin_msg "Deconfiguring network interfaces" if ifdown -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; force-reload|restart) process_options log_warning_msg "Running $0 $1 is deprecated because it may not enable again some interfaces" log_action_begin_msg "Reconfiguring network interfaces" ifdown -a --exclude=lo || true if ifup -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; *) echo "Usage: /etc/init.d/networking {start|stop}" exit 1 ;; esac exit 0

można znaleźć kilka funkcji sprawdzających zamontowane sieciowe systemy plików ( check_network_file_systems(), check_network_swap()), a także sprawdzanie istnienia jakiejś jeszcze niezrozumiałej konfiguracji /etc/sieć/opcje ( funkcjonować opcje_procesu()), a na samym dole po projekcie skrzynka „1 $” w i zgodnie z wprowadzonym parametrem (start/stop/force-reload|restart lub dowolny inny) wykonuje określone akcje. Z tych bardzo pewne działania", przykład argumentu start pokazuje, że funkcja jest uruchamiana jako pierwsza opcje_procesu, to fraza jest wysyłana do dziennika Konfigurowanie interfejsów sieciowych i uruchom polecenie jeśliup -a. Jeśli spojrzysz na man ifup , zobaczysz, że to polecenie odczytuje konfigurację z pliku /etc/network/interfaces i według klucza -A uruchamia wszystkie interfejsy, które mają ten parametr automatyczny.

Polecenia ifup i ifdown mogą służyć do konfigurowania (lub odpowiednio dekonfigurowania) interfejsów sieciowych w oparciu o definicje interfejsów w pliku /etc/network/interfaces.

-a, --wszystko
Jeśli podano ifup, wpływa na wszystkie interfejsy oznaczone jako auto. Interfejsy są wyświetlane w kolejności, w jakiej zostały zdefiniowane w /etc/network/interfaces. Jeśli podano ifdown, wpływa na wszystkie zdefiniowane interfejsy. Interfejsy są wyłączane w kolejności, w jakiej są aktualnie wymienione w pliku stanu. Wyłączone zostaną tylko interfejsy zdefiniowane w /etc/network/interfaces.

ip-server:~# cat /etc/network/interfaces # Ten plik opisuje interfejsy sieciowe dostępne w twoim systemie # i sposób ich aktywacji. Aby uzyskać więcej informacji, zobacz interfejsy(5). # Interfejs sieciowy pętli zwrotnej auto lo iface lo inet loopback # Podstawowy interfejs sieciowy allow-hotplug eth0 iface eth0 inet dhcp allow-hotplug eth2 iface eth2 inet adres statyczny 192.168.1.1 maska sieci 255.255.255.0 brama 192.168.1.254 broadcast 192.168.1.255

W tej linii konfiguracji Zezwól na hotplug I automatyczny są synonimami, a interfejsy zostaną uruchomione na żądanie jeśliup -a. To właściwie cały łańcuch działania podsystemu sieciowego. Podobnie w innych dystrybucjach: w RedHat i SUSE sieć jest uruchamiana przez skrypt /etc/init.d/network. Po zbadaniu go możesz podobnie znaleźć, gdzie leży konfiguracja sieci.

/etc/hosts

Ten plik zawiera listę adresy IP I odpowiadające im nazwy hostów (adresy).Format pliku nie różni się od pliku głównego:

Ip-server:~# cat /etc/hosts # ip host.w.domenie host 127.0.0.1 localhost 127.0.1.1 ip-server.domain.local ip-server 192.168.1.1 ip-server.domain.local ip-server

W przeszłości ten plik był używany zamiast usługi DNS. Obecnie plik może być również używany zamiast usługi DNS, ale tylko pod warunkiem, że ilość maszyn w Twojej sieci jest mierzona w jednostkach, a nie w dziesiątkach czy setkach, ponieważ w takim przypadku będziesz musiał kontrolować poprawność tego pliku na każdej maszynie.

/etc/nazwa_hosta

Ten plik zawiera Nazwa hosta NetBIOS:

Ip-server:~# cat /etc/hostname ip-server

Ten plik przechowuje nazwy i adresy sieci lokalnych i innych. Przykład:

Serwer IP: ~# cat /etc/networks domyślnie 0.0.0.0 sprzężenie zwrotne 127.0.0.0 łącze lokalne 169.254.0.0 sieć domowa 192.168.1.0

Korzystając z tego pliku, można zarządzać sieciami według nazwy. Na przykład dodaj trasę nie dodać trasę 192.168.1.12 , A dodać trasę.

/etc/nsswitch.conf

Plik definiuje kolejność wyszukiwania nazwy hosta/networks za to ustawienie odpowiadają następujące wiersze:

Dla hostów: hosty: pliki dns Dla sieci: sieci: pliki

Parametr akta określa użycie określonych plików (/etc/hosts I /etc/sieci odpowiednio), parametr dns określa korzystanie z usługi dns.

/etc/host.conf

Plik określa opcje rozpoznawania nazw dla programu tłumaczącego

Ip-server: ~# cat /etc/host.conf multi on

Ten plik mówi bibliotece resolv, aby zwróciła wszystkie prawidłowe adresy hostów znalezione w pliku /etc/hosts, a nie tylko pierwszy.

/etc/resolv.conf

Plik ten definiuje parametry mechanizmu translacji nazwy sieci na adres IP. W prostym języku definiuje ustawienia DNS. Przykład:

Ip-server: ~# cat /etc/resolv.conf nameserver 10.0.0.4 nameserver 10.0.0.1 search domain.local

Pierwsze 2 linie wskazać serwery DNS. Trzeci wiersz określa domeny wyszukiwania. Jeśli podczas rozpoznawania nazwy nazwa nie jest nazwą FQDN, wówczas ta domena jest zastępowana jako „koniec”. Na przykład podczas wykonywania polecenia ping host adres pingowany jest konwertowany na host.domain.local. Inne parametry można odczytać w man resolv.conf . Bardzo często Linux wykorzystuje dynamiczne generowanie tego pliku, wykorzystując tzw. programy /sbin/resolvconf. Ten program jest pośrednikiem między usługami, które dynamicznie udostępniają serwery nazw (np. Klient DHCP) i usług korzystających z danych serwera nazw. Aby użyć pliku generowanego dynamicznie /etc/resolv.conf, musisz ustawić ten plik jako dowiązanie symboliczne /etc/resolvconf/run/resolv.conf. W niektórych dystrybucjach ścieżka może być inna, na pewno zostanie to wpisane człowiek resolvconf.

Konfiguracja sieci

Po zapoznaniu się z głównymi plikami konfiguracyjnymi możesz zajrzeć do pliku . Polecenie zostało już wspomniane powyżej. jeśli up, jeśli w dół, ale te narzędzia nie są całkiem uniwersalne, na przykład w rozkładach RH te polecenia nie są domyślnie dostępne. Ponadto nowe dystrybucje posiadają nowe narzędzie do zarządzania siecią wysokiego poziomu - , które należy do pakietu iproute. Jemu (pakiet iproute) poświęcę . A w obecnym poście nie będę tego rozważać. Opisane poniżej polecenia należą do .

Aby więc mieć pewność, że polecenie będzie działać w dowolnej dystrybucji Linuksa, musisz użyć dwóch podstawowych staromodnych poleceń. To jest i arp. Pierwszy zespół (odpowiedzialny za konfigurowanie interfejsów sieciowych(ip, maska, brama), drugi () - konfiguracja routingu, trzeci (arp) - zarządzanie tabelą arp. Chciałbym zauważyć, że wykonanie tych poleceń bez wyłączania standardowego skryptu startowego SystemV podsystemu sieciowego spowoduje wprowadzenie zmian tylko do pierwszego ponownego uruchomienia / ponownego uruchomienia usługi sieciowej, ponieważ. jeśli pomyślisz o tym mózgiem, możesz zrozumieć, że scenariusz /etc/init.d/networking przy następnym uruchomieniu ponownie odczyta powyższe konfiguracje i zastosuje stare ustawienia. W związku z tym wyjściem na trwałe ustawienie ustawień jest albo polecenie ifconfig z odpowiednimi parametrami - wprowadź, lub ręcznie popraw odpowiednie konfiguracje interfejsu sieciowego.

Podobnie, jeśli polecenie ifconfig z brakującymi opcjami(na przykład tylko adres IP), reszta jest uzupełniana automatycznie (na przykład adres rozgłoszeniowy jest dodawany domyślnie z adresem hosta kończącym się na 255, a domyślna maska podsieci to 255.255.255.0).

Rozgromienie dla dostępnych interfejsów w nowoczesnych jądrach jest zawsze wywoływana automatycznie przez jądro. A raczej bezpośrednie trasy do sieci zgodnie z ustawieniami IP i podsieci, na którą wygląda podniesiony interfejs, są tworzone automatycznie przez jądro. Pole gateway (gateway) dla takich wpisów pokazuje adres interfejsu wyjściowego lub *. W starszych wersjach jądra (numer jądra, od którego trasy zaczynały rosnąć automatycznie - nie powiem), konieczne było ręczne dodanie trasy.

Jeśli istnieje potrzeba zorganizowania trasy, to musisz użyć . Możesz dodawać i usuwać trasy za pomocą tego polecenia, ale znowu pomoże to tylko do ponownego uruchomienia /etc/init.d/networking (lub innego skryptu sieciowego w twojej dystrybucji). Aby trasy były dodawane automatycznie, należy, podobnie jak w przypadku komendy ifconfig, dodać komendy dodawania tras do rc.local lub ręcznie poprawić odpowiednie konfiguracje interfejsu sieciowego (np. w Deb - /etc/sieć/opcje).

Według jakich zasad tworzone są trasy do sieci, Jestem w

Diagnostyka sieci Linux

W systemie Linux istnieje wiele narzędzi do diagnostyki sieci, często bardzo podobnych do narzędzi firmy Microsoft. Rozważę 3 główne narzędzia do diagnostyki sieci, bez których identyfikacja problemów będzie problematyczna.

Myślę, że to narzędzie jest znane prawie każdemu. Zadaniem tego narzędzia jest wysyłanie tak zwana pakiety ICMP zdalny serwer, który zostanie określony w parametrach polecenia, serwer zwraca wysłane polecenia i świstliczenie czasu wymagane, aby wysłany pakiet dotarł do serwera i wrócił. Na przykład:

# ping ya.ru PING ya.ru (87.250.251.3) 56(84) bajtów danych. 64 bajty z www.yandex.ru (87.250.251.3): icmp_seq=1 ttl=57 time=42,7 ms z www.yandex.ru (87.250.251.3): icmp_seq=3 ttl=57 time=42,5 ms 64 bajty z www .yandex.ru (87.250.251.3): icmp_seq=4 ttl=57 czas=42,5 ms 64 bajty z www .yandex.ru (87.250.251.3): icmp_seq=5 ttl=57 czas=41,9 ms ^C --- tak Statystyki .ru ping --- 5 wysłanych pakietów, 5 odebranych, 0% utraty pakietów, czas 4012ms rtt min/avg/max/mdev = 41,922/42,588/43,255/0,500ms

Jak widać z powyższego przykładu, świst dostarcza nam wielu przydatnych informacji. Przede wszystkim, dowiedzieliśmy się, że możemy nawiązać połączenie z hostem ya.ru(czasami mówią, że „host ya.ru jest dla nas dostępny”). Po drugie, widzimy to DNSy działają poprawnie, ponieważ „pingowana” nazwa została poprawnie przekonwertowana na adres IP (PING ya.ru (87.250.251.3)). Dalej, w polu icmp_seq= ustawia numerację wysyłanych pakietów. Każdemu wysłanemu pakietowi jest przypisywany sekwencyjnie numer, a jeśli w tej numeracji są „luki”, to powie nam to, że połączenie z „pingowanym” jest niestabilne, a także może oznaczać, że serwer, do którego wysyłane są pakiety jest przeciążony. Według wartości czas= widzimy, jak długo podróżowała paczka do 87.250.251.3 iz powrotem. Narzędzie ping można zatrzymać, naciskając kombinację klawiszy Ctrl+C.

Również, narzędzie do pingowania interesujące, ponieważ pozwala dokładnie zobaczyć, gdzie powstały problemy. Powiedzmy narzędzie do pingowania wyświetla komunikat sieć nieosiągalna lub inną podobną wiadomość. Najprawdopodobniej wskazuje to na nieprawidłową konfigurację systemu. W takim przypadku możesz wysłać pakiety na adres IP dostawcy usług internetowych, aby dowiedzieć się, gdzie występuje problem (między komputerem lokalnym lub „poza”). Jeśli masz połączenie z Internetem przez router, możesz wysyłać pakiety na jego adres IP. W związku z tym, jeśli problem pojawia się już na tym etapie, oznacza to nieprawidłową konfigurację systemu lokalnego lub uszkodzenie kabla, jeśli router odpowiada, a serwer dostawcy nie, to problem leży w kanale komunikacyjnym dostawcy itp. Wreszcie, jeśli konwersja nazwy na IP nie powiedzie się, możesz sprawdzić połączenie przez IP, jeśli odpowiedzi przyjdą poprawnie, możesz zgadnąć, że problem dotyczy DNS.

Należy zauważyć, że to narzędzie nie zawsze jest niezawodnym narzędziem diagnostycznym. Zdalny serwer może blokować odpowiedzi na żądania ICMP.

Trasa śledzenia

Mówiąc prościej, nazywa się zespół ślad trasy. Jak można zrozumieć z nazwy, to narzędzie pokaże, którą trasą pakiety trafiły do hosta. Narzędzie traceroute trochę podobny do świst, ale wyświetla bardziej interesujące informacje. Przykład:

# traceroute ya.ru traceroute do ya.ru (213.180.204.3), maks. 30 przeskoków, 60 bajtów pakietów .kubtelecom.ru (213.132.64.65) 2,761 ms 5,787 ms 5,777 ms 3 4) 5.713 ms 5,701 ms 5,636 ms 4 (194.186.6.177) 81,430 ms 81,581 ms 81,687 ms 5 213.33.201.230 (213.33.201.230) 43,322 ms 41,783 ms 41 . 106 ms 7 carmine-red-vlan602.yandex.net (87.250. 242.206) 41.199 ms 42.578 ms 42.610 ms 8 www.yandex.ru (213.180.204.3) 43.185 ms 42.126 ms 42.679 ms

Jak widać, możesz prześledzić trasę od routera dostawcy 243-083-free.kubtelecom.ru (213.132.83.243) (południe Rosji) do hosta końcowego pod adresem www.yandex.ru (213.180.204.3) w Moskwie.

kopać

To narzędzie wysyła zapytania do serwerów DNS i zwraca informacje o określonej domenie. Przykład:

# dig @ns.kuban.ru roboti.ru ;<<>> DiG 9.3.6-P1<<>> @ns.kuban.ru roboti.ru ; (1 serwer znaleziony) ;; opcje globalne: drukuj cmd ;; dostałem odpowiedź: ;; ->>NAGŁÓWEK<<- opcode: QUERY, status: NOERROR, id: 64412 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;roboti.ru. IN A ;; ANSWER SECTION: roboti.ru. 448 IN A 72.52.4.90 ;; AUTHORITY SECTION: roboti.ru. 345448 IN NS ns1.sedoparking.com. roboti.ru. 345448 IN NS ns2.sedoparking.com. ;; Query time: 102 msec ;; SERVER: 62.183.1.244#53(62.183.1.244) ;; WHEN: Thu Feb 17 19:44:59 2011 ;; MSG SIZE rcvd: 94

polecenie kopania wysłał prośbę serwer DNS - ns.kuban.ru (@ns.kuban.ru- ten parametr jest opcjonalny, w tym przypadku źródło informacji o DNS zostanie pobrane z serwera z ustawień systemu) o nazwie domeny roboti.ru. W efekcie otrzymałem odpowiedź, którą możemy zobaczyć w dziale SEKCJA ODPOWIEDZI informacje o adresach IP domeny, w sekcji SEKCJA WŁADZY informacje o tzw. autorytatywne serwery DNS. Trzecia linia od dołu mówi nam, który serwer dostarczył odpowiedź.

Inne narzędzia diagnostyczne

ping, dig i inne narzędzia diagnostyczne z parametrami znajdziecie w poście.

Podłączanie nowej karty sieciowej

Podłączenie i uruchomienie nowej karty sieciowej sprowadza się do kilku kroków:

1. Fizyczne podłączenie karty

3. Wyświetl dane wyjściowe dla systemu w celu wykrycia nowej karty sieciowej:

Zobaczmy wyjście PRZED podłączeniem nowej karty:

Serwer:~# dmesg | grep eth [ 4.720550] e1000: eth0: e1000_probe: Połączenie sieciowe Intel(R) PRO/1000 [ 5.130191] e1000: eth1: e1000_probe: Połączenie sieciowe Intel(R) PRO/1000 [ 15.285527] e1000: eth2: e1000_watchdog: łącze NIC jest Do 1000 Mb/s pełny dupleks, kontrola przepływu: RX [15.681056] e1000: eth0: e1000_watchdog: NIC Link działa do 1000 Mb/s, pełny dupleks, kontrola przepływu: RX

wyjście pokazuje, że system ma 2 karty sieciowe eth1 i eth2. Łączymy trzeci i patrzymy na dane wyjściowe:

Serwer:~# dmesg | grep eth [ 4.720513] e1000: eth0: e1000_probe: Połączenie sieciowe Intel(R) PRO/1000 [ 5.132029] e1000: eth1: e1000_probe: Połączenie sieciowe Intel(R) PRO/1000 [ 5.534684] e1000: eth2: e1000_probe: Intel(R) ) Połączenie sieciowe PRO/1000 [39.274875] udev: zmieniono nazwę interfejsu sieciowego z eth2 na eth3 [39.287661] udev: zmieniono nazwę interfejsu sieciowego z eth1_rename_ren na eth2 [45.670744] e1000: eth2: e1000_watchdog: Łącze karty sieciowej jest wyższe o 1000 Mb/s w trybie pełnego dupleksu, kontrola przepływu: R X [ 46.237232] e1000: eth0: e1000_watchdog: Łącze karty sieciowej działa z szybkością 1000 Mb/s w trybie pełnego dupleksu, kontrola przepływu: RX [96.977468] e1000: eth3: e1000_watchdog: Łącze karty sieciowej działa z szybkością 1000 Mb/s w trybie pełnego dupleksu, kontrola przepływu: RX

W dmesg widzimy, że pojawiła się nowa karta sieciowa - eth3, która w rzeczywistości jest eth2, ale została zmieniona przez menedżera urządzeń udev na eth3, a eth2 jest w rzeczywistości przemianowaną na eth1 (o udev porozmawiamy w osobnym poście). Wygląd naszej nowej sieci w dmesg mówi nam, że karta sieciowa utrzymany zasadnicza i poprawna zdecydowany. Pozostało tylko skonfigurować nowy interfejs w /etc/network/interfaces(Debian), ponieważ dana mapa nie została zainicjowana przez skrypt startowy /etc/init.d/network. ifconfig widzi tę kartę:

Serwer:~# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 08:00:27:5f:34:ad inet6 adres: fe80::a00:27ff:fe5f:34ad/64 Zakres:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metryczne: 1 pakiety RX:311847 błędy:0 porzucone:0 przekroczenia:0 ramka:0 pakiety TX:126 błędy:0 porzucone:0 przekroczenia:0 przewoźnik:0 kolizje:0 txqueuelen:1000 bajty RX:104670651 (99,8 MiB) bajty TX: 16184 (15,8 KiB)

ale poza tym - nie konfiguruje. Jak skonfigurować kartę sieciową omówiono powyżej.

Streszczenie

Myślę, że to wszystko na dzisiaj. Kiedy zaczynałem pisać ten artykuł, myślałem, że zmieszczę się w jednym poście, ale okazało się, że jest ogromny. Dlatego zdecydowano się podzielić artykuł na dwie części. W sumie starałem się podać nie krok po kroku jak skonfigurować sieć, ale podać zasadę i wyjaśnić zrozumienie jak sieć się uruchamia i działa w Linuksie. Naprawdę mam nadzieję, że mi się udało. Będę zadowolony z twoich komentarzy i uzupełnień. Z czasem uzupełnię artykuł.

Po podzieleniu sieci na podsieci należy przygotować się do prostego wyszukiwania adresów według nazw za pomocą pliku /etc/hosts. Jeśli nie zamierzasz używać do tego DNS lub NIS, musisz wprowadzić wszystkie hosty plik hosta.

Nawet jeśli chcesz używać DNS lub NIS, możesz również mieć pewien podzbiór nazw w /etc/hosts. Na przykład, jeśli chcesz wyszukiwać nazwy nawet wtedy, gdy interfejsy sieciowe nie są uruchomione, na przykład podczas uruchamiania. Jest to nie tylko kwestia wygody, ale także pozwala używać symbolicznych nazw hostów w skryptach rc. Dlatego podczas zmiany adresów IP będziesz musiał tylko skopiować zaktualizowany plik hosts na wszystkie komputery, zamiast edytować wiele plików rc. Zazwyczaj umieszczasz wszystkie lokalne nazwy i adresy w hostach, dodając je do dowolnej bramy i serwera NIS, jeśli jest używany.

Ponadto podczas sprawdzania należy upewnić się, że serwer nazw używa tylko informacji z pliku hosts. Oprogramowanie DNS lub NIS może zawierać przykładowe pliki, których użycie może dawać dziwne wyniki. Aby wymusić, aby wszystkie aplikacje korzystały wyłącznie z pliku /etc/hosts podczas wyszukiwania adresu IP hosta, należy zmodyfikować plik /etc/host.conf. Zakomentuj wszystkie wiersze zaczynające się od kolejności słów kluczowych i wklej wiersz:

zamów hosty

Konfiguracja biblioteki serwera nazw zostanie szczegółowo opisana w rozdziale 6.

Plik hosts zawiera jeden wpis w każdym wierszu, składający się z adresu IP, nazwy hosta i opcjonalnej listy aliasów. Pola oddzielone są spacjami lub tabulatorami, pole adresowe musi zaczynać się w pierwszej kolumnie. Wszystko po symbolu # jest traktowane jako komentarz i ignorowane.

Nazwa hosta może być w pełni kwalifikowana lub odnosić się do domeny lokalnej. W przypadku vale należy wprowadzić w pełni kwalifikowaną nazwę, vale.vbrew.com , do hosts , a także samą vale, aby znana była zarówno nazwa oficjalna, jak i krótsza nazwa lokalna.

Poniżej podano przykładowy plik hosts dla Virtual Brewery. Dwie specjalne nazwy, vlager-if1 i vlager-if2 , określają adresy dla obu interfejsów używanych w vlager .

Jakie jest praktyczne zastosowanie pliku /etc/networks? O ile rozumiem, w tym pliku można określić nazwy sieci. Na przykład:

[e-mail chroniony]:~# cat /etc/networks domyślnie 0.0.0.0 sprzężenie zwrotne 127.0.0.0 łącze lokalne 169.254.0.0 google-dns 8.8.4.4 [e-mail chroniony]:~#

Jeśli jednak spróbuję użyć tej nazwy sieci, na przykład w narzędziu ip, to nie działa:

[e-mail chroniony]:~# ip route dodaj google-dns przez 104.236.63.1 dev eth0 Błąd: oczekiwany jest przedrostek inet zamiast „google-dns”. [e-mail chroniony]:~# trasa ip dodaj 8.8.4.4 przez 104.236.64.1 dev eth0 [e-mail chroniony]:~#

Jakie jest praktyczne zastosowanie pliku /etc/networks?

2 Rozwiązania zbierane z sieci w celu „praktycznego wykorzystania pliku /etc/networks”

Jak napisano w podręczniku, plik /etc/networks powinien opisywać symboliczne nazwy sieci. W przypadku sieci oznacza to adres sieciowy z końcówką .0 na końcu. Obsługiwane są tylko proste sieci klasy A, B lub C.

W twoim przykładzie wpis google-dns jest nieprawidłowy. To nie jest sieć A, B ani C. To relacja ip-address-hostname, więc należy do /etc/hosts . W rzeczywistości domyślny wpis też nie pasuje.

Załóżmy, że masz adres IP 192.168.1.5 z sieci firmowej. Wpis w /etc/network może wyglądać następująco:

Nazwa firmy 192.168.1.0

Podczas korzystania z narzędzi, takich jak route lub netstat , sieci te są tłumaczone (chyba że wyłączysz uprawnienia za pomocą flagi -n). Tabela routingu może wyglądać następująco:

Tabela routingu IP jądra Brama docelowa Genmask Flagi Metric Ref Użyj Iface default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 nazwa firmy * 255.255.255.0 U 0 0 0 eth0

Polecenie ip nigdy nie używa nazwy hosta do wprowadzania danych, więc twój przykład nie ma większego znaczenia. Umieściłeś także nazwę hosta w /etc/networks , a nie nazwę sieci!

Wpisy w /etc/networks są używane przez narzędzia, które próbują konwertować liczby na nazwy, takie jak (przestarzałe) polecenie route. Bez odpowiedniego wpisu pokazuje:

# trasa Jądro Tabela routingu IP Brama docelowa Genmask Flagi Metryka Ref Użyj Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 * 255.255.254.0 U 0 0 0 eth0

Jeśli teraz dodamy linię mylocalnet 192.168.0.0 do /etc/networks:

# trasa Jądro Tabela routingu IP Brama docelowa Genmask Flagi Metryka Ref Użyj Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 mylocalnet * 255.255.254.0 U 0 0 0 eth0

W praktyce to nigdy nie jest używane.

Iść!

Protokół Network File Server (NFS) to otwarty standard zapewniający użytkownikowi zdalny dostęp do systemów plików. Oparte na nim scentralizowane systemy plików ułatwiają wykonywanie codziennych zadań, takich jak tworzenie kopii zapasowych lub sprawdzanie wirusów, a połączone partycje dyskowe są łatwiejsze w utrzymaniu niż wiele małych i rozproszonych partycji.

Oprócz zapewniania scentralizowanej pamięci masowej system NFS okazał się bardzo przydatny w przypadku innych aplikacji, w tym klientów bezdyskowych i cienkich, klastrów sieciowych i oprogramowania pośredniego do współpracy.

Lepsze zrozumienie zarówno samego protokołu, jak i szczegółów jego implementacji ułatwi rozwiązywanie praktycznych problemów. Ten artykuł jest poświęcony NFS i składa się z dwóch części logicznych: najpierw opisano sam protokół i cele postawione podczas jego tworzenia, a następnie implementację NFS w systemach Solaris i UNIX.

GDZIE WSZYSTKO SIĘ ZACZĘŁO...

Protokół NFS został opracowany przez Sun Microsystems i pojawił się w Internecie w 1989 roku jako RFC 1094 pod następującym tytułem: Network File System Protocol Specification (NFS). Warto zauważyć, że strategia firmy Novell w tamtym czasie polegała na dalszym ulepszaniu usług związanych z plikami. Jeszcze do niedawna, gdy ruch open source był jeszcze w pełnym rozkwicie, Sun nie chciał zdradzać tajemnic swoich rozwiązań sieciowych, ale już wtedy firma rozumiała, jak ważna jest interoperacyjność z innymi systemami.

RFC 1094 zawierał dwie oryginalne specyfikacje. W momencie publikacji firma Sun opracowywała kolejną, trzecią wersję specyfikacji, która jest zawarta w dokumencie RFC 1813 „NFS Protocol Specification, Version 3” (NFS Version 3 Protocol Specification). Wersja 4 tego protokołu jest zdefiniowana w dokumencie RFC 3010 NFS Protocol Specification Version 4 (NFS Version 4 Protocol).

NFS jest szeroko stosowany we wszystkich typach hostów UNIX, sieciach Microsoft i Novell oraz rozwiązaniach IBM, takich jak AS400 i OS/390. Nieznany poza dziedziną sieci, NFS jest prawdopodobnie najczęściej używanym niezależnym od platformy sieciowym systemem plików.

UNIX BYŁ GENERATOREM

Chociaż NFS jest systemem niezależnym od platformy, UNIX jest jego przodkiem. Innymi słowy, hierarchiczna architektura i metody dostępu do plików, w tym struktura systemu plików, sposoby identyfikowania użytkowników i grup oraz sposób obsługi plików, są bardzo podobne do systemu plików UNIX. Na przykład system plików NFS, który ma identyczną strukturę jak system plików UNIX jest montowany bezpośrednio na nim. Podczas pracy z NFS w innych systemach operacyjnych tożsamości użytkowników i uprawnienia do plików są odwzorowywane.

NFS

System NFS jest przeznaczony do stosowania w architekturze klient-serwer. Klient uzyskuje dostęp do systemu plików wyeksportowanego przez serwer NFS za pośrednictwem punktu montowania na kliencie. Taki dostęp jest zwykle przezroczysty dla aplikacji klienckiej.

W przeciwieństwie do wielu systemów typu klient/serwer, NFS używa zdalnych wywołań procedur (RPC) do wymiany informacji. Zazwyczaj klient nawiązuje połączenie ze znanym portem, a następnie zgodnie z protokołem wysyła żądanie wykonania określonej akcji. W przypadku zdalnego wywołania procedury klient tworzy wywołanie procedury, a następnie wysyła je do wykonania na serwerze. Szczegółowy opis NFS zostanie przedstawiony poniżej.

Załóżmy na przykład, że klient zamontował katalog usr2 w lokalnym głównym systemie plików:

/root/usr2/ -> zdalny:/root/usr/

Jeśli aplikacja kliencka potrzebuje zasobów tego katalogu, po prostu wysyła żądanie do systemu operacyjnego i nazwy pliku, który zapewnia dostęp za pośrednictwem klienta NFS. Rozważmy na przykład proste polecenie CD systemu UNIX, które „nic nie wie” o protokołach sieciowych. Zespół

CD /root/usr2/

umieści katalog roboczy w zdalnym systemie plików, „nawet nie wiedząc” (użytkownik też nie musi wiedzieć), że system plików jest zdalny.

Po otrzymaniu żądania serwer NFS sprawdzi, czy dany użytkownik ma uprawnienia do wykonania żądanej akcji iw przypadku pozytywnej odpowiedzi wykona ją.

POZNAJMY SIĘ LEPIEJ

Z punktu widzenia klienta proces montowania zdalnego systemu plików lokalnie za pomocą NFS składa się z kilku kroków. Jak już wspomniano, klient NFS wyśle zdalne wywołanie procedury w celu wykonania jej na serwerze. Należy zauważyć, że w systemie UNIX klient jest pojedynczym programem (polecenie montowania), podczas gdy serwer jest w rzeczywistości zaimplementowany jako kilka programów z następującym minimalnym zestawem: usługa mapowania portów (port mapper), demon montowania (demon montowania) i serwer NFS.

Polecenie mount klienta najpierw komunikuje się z usługą translacji portów serwera, która nasłuchuje żądań na porcie 111. Większość implementacji polecenia mount klienta obsługuje wiele wersji NFS, co zwiększa prawdopodobieństwo, że klient i serwer znajdą wspólną wersję protokołu. Wyszukiwanie odbywa się począwszy od najstarszej wersji, więc gdy zostanie znaleziona wspólna, automatycznie stanie się najnowszą wersją obsługiwaną przez klienta i serwer.

(Ten materiał koncentruje się na trzeciej wersji NFS, ponieważ jest ona obecnie najpopularniejsza. Czwarta wersja nie jest jeszcze obsługiwana przez większość implementacji.)

Usługa translacji portów serwera odpowiada na żądania zgodnie z obsługiwanym protokołem i portem, na którym działa demon montowania. Program montowania klienta najpierw ustanawia połączenie z demonem montowania serwera, a następnie wysyła do niego polecenie montowania przez RPC. Jeśli ta procedura zakończy się pomyślnie, aplikacja kliencka łączy się z serwerem NFS (port 2049) i za pomocą jednej z 20 zdalnych procedur zdefiniowanych w dokumencie RFC 1813 i wymienionych w tabeli 1 uzyskuje dostęp do zdalnego systemu plików.

Znaczenie większości poleceń jest intuicyjne i nie sprawia trudności administratorom systemu. Poniższa lista, utworzona przy użyciu tcdump, ilustruje polecenie read używane przez polecenie cat w systemie UNIX do odczytania pliku o nazwie plik-testowy:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: wyszukiwanie 144 fh 32.0/ 224145 "plik testowy" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 wyszukiwanie fh 32.0/ 224145 "plik-testowy" 10:30:16.012729 eth0 192.168.1.254.3476097947: odpowiedz ok 128 wyszukiwanie fh 32.0/22 4307 (DF) 10:30: 16.012729 eth0 192.168.1.254.3476097947: odpowiedz ok 128 wyszukiwanie fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 odczyt fh 32.0/ 224307 4096 bajtów @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 odczyt fh 32.0/ 224307 4096 bajtów @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163: odpowiedź ok 108 odczyt (DF) 10: 30:16.013650 eth0 192.168.1.254.3492875163 : odpowiedź ok 108 odczyt (DF)

NFS był tradycyjnie wdrażany przez UDP. Jednak niektóre wersje NFS obsługują protokół TCP (obsługa protokołu TCP jest zdefiniowana w specyfikacji protokołu). Główną zaletą protokołu TCP jest wydajniejszy mechanizm retransmisji w zawodnych sieciach. (W przypadku UDP, jeśli wystąpi błąd, retransmitowana jest cała wiadomość RPC, składająca się z kilku pakietów UDP. W przypadku protokołu TCP retransmitowany jest tylko uszkodzony fragment.)

DOSTĘP DO NFS

Implementacje NFS zazwyczaj obsługują cztery metody udzielania dostępu: poprzez atrybuty użytkownika/pliku, na poziomie udziału, na poziomie węzła głównego oraz jako kombinacja innych metod dostępu.

Pierwsza metoda opiera się na wbudowanym systemu UNIX uprawnienia do plików dla pojedynczego użytkownika lub grupy. Aby uprościć konserwację, identyfikacja użytkowników i grup powinna być spójna we wszystkich klientach i serwerach NFS. Bezpieczeństwo musi być starannie rozważone: NFS może nieumyślnie udzielić dostępu do plików, które nie były zamierzone podczas ich tworzenia.

Dostęp do zasobów współdzielonych umożliwia ograniczenie uprawnień tylko do określonych działań, niezależnie od własności pliku lub uprawnień w systemie UNIX. Na przykład praca z systemem plików NFS może być ograniczona tylko do odczytu. Większość implementacji NFS umożliwia dalsze ograniczanie dostępu na poziomie współdzielonych zasobów do określonych użytkowników i/lub grup. Na przykład grupa Human Resources może przeglądać informacje i nic więcej.

Dostęp na poziomie głównym umożliwia montowanie systemu plików tylko na określonych węzłach, co ogólnie jest dobrym pomysłem, ponieważ systemy plików można łatwo tworzyć na dowolnych węzłach obsługujących NFS.

Dostęp łączony po prostu łączy powyższe typy (na przykład dostęp na poziomie udziału z dostępem przyznanym określonemu użytkownikowi) lub umożliwia użytkownikom dostęp do NFS tylko z określonego hosta.

STYL PINGWINA NFS

Prezentowany tutaj materiał związany z Linuksem bazuje na systemie Red Hat 6.2 z jądrem w wersji 2.4.9, dostarczanym wraz z wersją 0.1.6 pakietu nfs-utils. Istnieją również nowsze wersje: w chwili pisania tego tekstu najnowsza aktualizacja pakietu nfs-utils to 0.3.1. Można go pobrać pod adresem: .

Pakiet nfs-utils zawiera następujące elementy pliki wykonywalne: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount i statd.

Niestety, obsługa NFS jest czasami myląca dla administratorów Linuksa, ponieważ dostępność określonej funkcji jest bezpośrednio zależna od numerów wersji zarówno jądra, jak i pakietu nfs-utils. Na szczęście sytuacja w tej dziedzinie się poprawia: najnowsze zestawy dystrybucyjne zawierają najnowsze wersje obu. Aby zapoznać się z pełną listą poprzednich wydań, zobacz sekcję 2.4 NFS-HOWTO funkcjonalność systemy dostępne dla każdej kombinacji pakietu jądra i nfs-utils. Twórcy zachowują kompatybilność wsteczną pakietu z wcześniejszymi wersjami, przykładając dużą wagę do bezpieczeństwa i naprawiania błędów oprogramowania.

Obsługa NFS musi być zainicjowana w czasie kompilacji jądra. W razie potrzeby do jądra należy również dodać możliwość pracy z NFS w wersji 3.

W przypadku dystrybucji obsługujących linuxconf konfiguracja usług NFS zarówno dla klientów, jak i serwerów jest łatwa. Jednak szybki sposób konfiguracji NFS za pomocą linuxconf nie dostarcza informacji o tym, jakie pliki zostały utworzone lub edytowane, co jest bardzo ważne dla administratora, aby wiedzieć w przypadku awarii systemu. Architektura NFS w systemie Linux jest luźno powiązana z wersją BSD, więc niezbędne pliki i programy pomocnicze są łatwe do znalezienia dla administratorów korzystających z BSD, Sun OS 2.5 lub wcześniejszych wersji NFS.

Plik /etc/exports, podobnie jak we wcześniejszych wersjach BSD, określa systemy plików, do których klienci NFS mają dostęp. Ponadto zawiera numer dodatkowe funkcje związane z zarządzaniem i kwestiami bezpieczeństwa, dające administratorowi narzędzie do dostrajania. Ten plik tekstowy, składający się z wpisów, pustych wierszy lub wierszy z komentarzem (komentarze zaczynają się od #).

Powiedzmy, że chcemy dać klientom dostęp tylko do odczytu do katalogu /home na hoście Lefty. Odpowiadałoby to następującemu wpisowi w /etc/exports:

/dom (ro)

Tutaj musimy powiedzieć systemowi, które katalogi udostępnimy za pomocą demona montowania rpc.mountd:

# exportfs -r exportfs: Nie określono nazwy hosta w /home (ro), wpisz *(ro), aby uniknąć ostrzeżenia #

Po uruchomieniu polecenie exportfs ostrzega, że /etc/exports nie ogranicza dostępu do określonego węzła i tworzy odpowiedni wpis w /var/lib/nfs/etab z /etc/exports informujący, które zasoby można przeglądać za pomocą cat:

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Inne opcje wymienione w etab obejmują ustawienia domyślne używane przez NFS. Szczegóły zostaną opisane poniżej. Aby przyznać dostęp do katalogu /home, należy uruchomić odpowiednie usługi NFS:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

W dowolnym momencie po uruchomieniu demona montowania (rpc.mountd) możesz zapytać o poszczególne pliki dostępne do wyjścia, przeglądając zawartość pliku /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Wersja 1.0 # Klient ścieżki (flagi) # Adresy IP /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

To samo można wyświetlić za pomocą polecenia showmount z opcją -e:

# showmount -e Eksportuj listę dla lefty: /home (wszyscy) #

Idąc nieco dalej, polecenie showmount może być również użyte do określenia wszystkich zamontowanych systemów plików, czyli innymi słowy, aby dowiedzieć się, które hosty są klientami NFS dla systemu, na którym uruchomiono polecenie showmount. Polecenie showmount -a wyświetli listę wszystkich punktów montowania klienta:

# showmount -a Wszystkie punkty montowania po lewej stronie: 192.168.1.252:/home #

Jak wspomniano powyżej, większość implementacji NFS obsługuje różne wersje tego protokołu. Implementacja Linuksa pozwala ograniczyć listę wersji NFS, które będą uruchamiane, określając opcję -N dla demona montowania. Na przykład, aby uruchomić NFS w wersji 3 i tylko w wersji 3, wprowadź następującą komendę:

# rpc.mountd -N 1 -N 2

Wybrednym użytkownikom może wydawać się niewygodne, że w systemie Linux demon NFS (rpc.nfsd) czeka na pakiety w wersji 1 i wersji 2, chociaż osiąga to pożądany efekt w postaci braku obsługi odpowiedniego protokołu. Miejmy nadzieję, że twórcy kolejnych wersji wprowadzą niezbędne poprawki i będą w stanie osiągnąć większą spójność między składnikami pakietu w stosunku do różnych wersji protokołu.

„PŁYWANIE Z PINGWINAMI”

Dostęp do wyżej skonfigurowanego eksportowalnego systemu plików NFS opartego na systemie Linux, Lefty, jest zależny od systemu operacyjnego klienta. Styl ustawień dla większości systemów operacyjnych rodziny UNIX pasuje do stylu oryginalnych systemów Sun OS i BSD lub nowszego Solarisa. Ponieważ ten artykuł skupia się zarówno na Linuksie, jak i Solarisie, spójrzmy na konfigurację klienta Solarisa 2.6 z punktu widzenia nawiązywania połączenia z opisaną powyżej linuksową wersją NFS.

Dzięki funkcjom odziedziczonym po Solarisie 2.6 można go łatwo skonfigurować do działania jako klient NFS. Wymaga to tylko jednego polecenia:

# zamontować -F nfs 192.168.1.254:/home /tmp/tmp2

Zakładając, że poprzednie polecenie montowania powiodło się, polecenie montowania bez opcji wyświetli następujące informacje:

# mount / on /dev/dsk/c0t0d0s0 odczyt/zapis/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home odczyt/ zapis/remote on Pon 3 września 23:19:25 2001

Przeanalizujmy dane wyjściowe tcpdump na hoście Lefty po wprowadzeniu przez użytkownika polecenia ls /tmp/tmp2 na hoście Sunny:

# tcpdump host lefty i host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny. 2191983953: odpowiedz ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 dostęp fh Unknown/10001 (DF) 06:07:4 3.491463 lewy mcwrite.n.nfs > sunny.2191983954: odpowiedz ok 120 dostęp c0001 (DF) 06:07:43.492296 00 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: odpowiedz ok 1000 readdirplus ( DF)

Widzimy, że węzeł Sunny prosi o deskryptor pliku (fh) dla ls, na co węzeł Lefty wysyła w odpowiedzi OK i zwraca strukturę katalogów. Następnie Sunny sprawdza uprawnienia do zawartości katalogu (132 access fh) i otrzymuje odpowiedź dotyczącą pozwolenia od Lefty'ego. Następnie węzeł Sunny odczytuje pełną zawartość katalogu za pomocą procedury readdirplus. Zdalne wywołania procedur są opisane w dokumencie RFC 1813 i są wymienione na początku tego artykułu.

Chociaż sekwencja poleceń dostępu do zdalnych systemów plików jest bardzo prosta, kilka okoliczności może spowodować nieprawidłowe zamontowanie systemu. Przed zamontowaniem katalogu punkt montowania musi już istnieć, w przeciwnym razie należy go utworzyć za pomocą polecenia mkdir. Zwykle jedyną przyczyną błędów po stronie klienta jest brak lokalnego katalogu montowania. Większość problemów związanych z NFS ma jednak swoje źródło w niezgodności między klientem a serwerem lub nieprawidłowej konfiguracji serwera.

Najłatwiejszym sposobem rozwiązywania problemów na serwerze jest host, na którym działa serwer. Jednak gdy ktoś inny administruje serwerem zamiast Ciebie, nie zawsze jest to możliwe. Szybki sposób upewnij się, że odpowiednie usługi serwera są poprawnie skonfigurowane - użyj polecenia rpcinfo z opcją -p. Z hosta Solaris Sunny możesz określić, które procesy RPC są zarejestrowane na hoście z systemem Linux:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 102 4 montowany /100005 3 tcp 1024 montowany 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Należy zauważyć, że podano tutaj również informacje o wersji, co jest bardzo przydatne, gdy system wymaga obsługi różnych protokołów NFS. Jeśli jakakolwiek usługa nie jest uruchomiona na serwerze, należy poprawić tę sytuację. Jeśli montowanie nie powiedzie się, następujące polecenie rpcinfo -p poinformuje, że usługa mountd na serwerze nie działa:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Polecenie rpcinfo jest bardzo przydatne do sprawdzania, czy dany zdalny proces jest aktywny. Opcja -p jest najważniejszym z przełączników. Zobacz stronę podręcznika dla wszystkich funkcji rpcinfo.

Innym przydatnym narzędziem jest polecenie nfsstat. Z jego pomocą można dowiedzieć się, czy klienci faktycznie uzyskują dostęp do wyeksportowanego systemu plików, a także wyświetlić informacje statystyczne zgodnie z wersją protokołu.

Wreszcie innym dość przydatnym narzędziem do określania przyczyn awarii systemu jest tcpdump:

# tcpdump host lefty i host sunny -s512 tcpdump: słuchanie na eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 wyszukiwanie fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: odpowiedź ok 116 wyszukiwanie BŁĄD: Brak takiego pliku lub katalogu (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 ( DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: odpowiedz ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcw rytuał .n.nfs : 140 wyszukiwanie fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: odpowiedź ok 116 wyszukiwanie BŁĄD: Brak takiego pliku lub katalogu (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 utwórz fh Nieznany/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: odpowiedz ok 120 utwórz BŁĄD: Odmowa pozwolenia (DF)

Powyższy listing uzyskany po wykonaniu instrukcji touch test.c przedstawia następującą sekwencję działań: najpierw komenda touch próbuje uzyskać dostęp do pliku o nazwie test.c, następnie szuka katalogu o tej samej nazwie, a po niepowodzeniu próbuje, próbuje utworzyć plik test.c , co również kończy się niepowodzeniem.

Jeśli system plików jest zamontowany, większość typowych błędów jest związana z normalnymi uprawnieniami systemu UNIX. Używanie przez firmę Sun uid lub NIS+ pozwala uniknąć globalnego ustawiania uprawnień we wszystkich systemach plików. Niektórzy administratorzy praktykują „otwarte” katalogi, w których uprawnienia do ich odczytu nadawane są „całemu światu”. Należy tego jednak unikać ze względów bezpieczeństwa. Pomijając kwestie bezpieczeństwa, jest to nadal zła praktyka, ponieważ użytkownicy rzadko tworzą dane z zamiarem uczynienia ich czytelnymi dla wszystkich.

Dostęp uprzywilejowanego użytkownika (root) do systemów plików podłączonych przez NFS jest traktowany inaczej. Aby uniknąć przyznawania nieograniczonego dostępu użytkownikowi uprzywilejowanemu, żądania od użytkownika uprzywilejowanego są traktowane tak, jakby pochodziły od użytkownika „nikt”. Ten potężny mechanizm ogranicza dostęp uprzywilejowanych użytkowników do globalnie zapisywalnych i odczytywanych plików.

SERWER NFS, WERSJA SOLARIS

Skonfigurowanie systemu Solaris do działania jako serwer NFS jest tak proste, jak w systemie Linux. Jednak polecenia i lokalizacje plików są nieco inne. Gdy system Solaris zostanie uruchomiony, gdy zostanie osiągnięty poziom rozruchu 3, usługi NFS zostaną automatycznie uruchomione, a wszystkie systemy plików zostaną wyeksportowane. Aby ręcznie uruchomić te procesy, wprowadź polecenie:

#/usr/lib/nfs/mountd

Aby uruchomić demona montowania i serwer NFS, wpisz:

#/usr/lib/nfs/nfsd

Począwszy od wersji 2.6, Solaris nie używa już pliku eksportu do określania, które systemy plików mają zostać wyeksportowane. Pliki są teraz eksportowane za pomocą polecenia udostępniania. Załóżmy, że chcemy zezwolić zdalnym hostom na montowanie /export/home. Aby to zrobić, wprowadź następujące polecenie:

Udostępnij -F nfs /export/home

Środki bezpieczeństwa

BEZPIECZEŃSTWO W LINUXIE

Niektóre usługi systemowe NFS oparte na systemie Linux mają dodatkowy mechanizm ograniczania dostępu za pomocą list kontrolnych lub tabel. Na poziomie wewnętrznym mechanizm ten jest realizowany za pomocą biblioteki tcp_wrapper, która wykorzystuje dwa pliki do tworzenia list kontroli dostępu: /etc/hosts.allow i /etc/hosts/deny. Wyczerpujący przegląd zasad pracy z tcp_wrapper wykracza poza zakres tego artykułu, ale podstawowa zasada jest następująca: dopasowywanie odbywa się najpierw za pomocą pliku etc/hosts.allow, a następnie pliku /etc/hosts. zaprzeczyć. Jeśli reguła nie zostanie znaleziona, żądana usługa systemowa nie zostanie przedstawiona. Aby obejść ostatnie wymaganie i zapewnić bardzo wysoki poziom bezpieczeństwa, możesz dodać następujący wpis na końcu pliku /etc/hosts.deny:

Wszystko wszystko

Następnie /etc/hosts.allow można użyć do ustawienia tego lub innego trybu działania. Na przykład plik /etc/hosts. allow , którego użyłem podczas pisania tego artykułu, zawierał następujące wiersze:

lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 statd:192 . 168.1.0/255.255.255.0

Umożliwia to pewnego rodzaju dostęp do węzłów przed przyznaniem dostępu na poziomie aplikacji. W Dostęp do Linuksa na poziomie aplikacji kontrolki plików /etc/exports. Składa się z wpisów w następującym formacie:

Eksportuj katalog (spacja) host|sieć(opcje)

„Wyeksportowany katalog” to katalog, dla którego demon nfsd może przetworzyć żądanie. „Host|Sieć” to host lub sieć, która ma dostęp do wyeksportowanego systemu plików, a „opcje” określają, jakie ograniczenia demon nfsd nakłada na korzystanie z tego współdzielonego zasobu — dostęp tylko do odczytu lub mapowanie identyfikatora użytkownika.

Poniższy przykład przyznaje całej domenie mcwrite.net dostęp tylko do odczytu do /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

Więcej przykładów można znaleźć na stronie podręcznika eksportu.

BEZPIECZEŃSTWO NFS W SOLARIS

W Solarisie możliwość zapewnienia dostępu NFS jest podobna do Linuksa, ale w tym przypadku ograniczenia są ustawiane za pomocą pewnych opcji w poleceniu share z przełącznikiem -o. Poniższy przykład pokazuje, jak włączyć montowanie /export/mcwrite.net tylko do odczytu na dowolnym hoście w domenie mcwrite.net:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

Strona podręcznika share_nfs szczegółowo opisuje sposób udzielania dostępu za pomocą list kontrolnych w systemie Solaris.

Zasoby internetowe

NFS i RPC nie były pozbawione „dziur”. Ogólnie rzecz biorąc, NFS nie powinien być używany w Internecie. Nie można „przedziurawić” zapór ogniowych, zezwalając na dostęp dowolnego rodzaju przez NFS. Wszystkie poprawki RPC i NFS powinny być ściśle monitorowane, a liczne źródła informacji o zabezpieczeniach mogą w tym pomóc. Dwa najpopularniejsze źródła to Bugtraq i CERT:

Te pierwsze można przeglądać regularnie w poszukiwaniu potrzebnych informacji lub skorzystać z subskrypcji okresowego newslettera. Drugi dostarcza, być może, nie tak szybko, w porównaniu z innymi, informacji, ale w dość pełnej objętości i bez cienia sensacji, charakterystycznej dla niektórych witryn poświęconych bezpieczeństwu informacji.

Niekiedy błędy sieci i inne błędy systemu Windows mogą mieć swoje podłoże w problemach występujących w rejestrze systemu Windows. Kilka programów może używać pliku sieci, jednak w momencie ich usunięcia lub modyfikacji pozostawiane są niekiedy osierocone (nieprawidłowe) wpisy rejestru systemu Windows.

Zasadniczo oznacza to, że chociaż rzeczywista ścieżka do pliku mogła zostać zmieniona, jego nieprawidłowa poprzednia lokalizacja jest nadal rejestrowana w rejestrze systemu Windows. Gdy system Windows próbuje odszukać nieprawidłowe odwołanie do tego pliku (lokalizacje pliku na komputerze), występują błędy network. Ponadto zainfekowanie złośliwym oprogramowaniem może spowodować uszkodzenie wpisów rejestru związanych z Microsoft Windows. W związku z tym te uszkodzone wpisy rejestru systemu Windows muszą zostać naprawione, aby naprawić przyczynę problemu.

Ręczna edycja rejestru systemu Windows w celu usunięcia nieprawidłowego klucza sieciowego nie jest zalecana, chyba że jesteś profesjonalnym serwisem komputerowym. Błędy popełnione podczas edytowania rejestru mogą uniemożliwić korzystanie z komputera i spowodować nieodwracalne uszkodzenie systemu operacyjnego. W rzeczywistości nawet pojedynczy przecinek w niewłaściwym miejscu może uniemożliwić uruchomienie komputera!

Ze względu na to ryzyko stanowczo zalecamy korzystanie z zaufanego narzędzia do czyszczenia rejestru, takiego jak WinThruster (stworzonego przez firmę posiadającą tytuł Microsoft Gold Certified Partner), które umożliwia skanowanie i naprawianie dowolnych sieci. Używanie narzędzia do czyszczenia rejestru automatyzuje proces znajdowania nieprawidłowych wpisów w rejestrze, brakujących odniesień do plików (takich jak to, które powoduje błąd sieci) oraz niedziałających łączy w rejestrze. Przed każdym skanowaniem tworzony jest automatycznie plik kopia zapasowa, który umożliwia cofnięcie wszelkich zmian jednym kliknięciem i chroni przed ewentualnym uszkodzeniem komputera. Najlepsze jest to, że naprawa błędów rejestru może drastycznie poprawić szybkość i wydajność systemu.

Ostrzeżenie: Jeśli nie jesteś doświadczony użytkownik PC, NIE zalecamy ręcznej edycji rejestru systemu Windows. Nieprawidłowe użycie Edytora rejestru może prowadzić do poważnych problemów i wymagać ponownej instalacji systemu Windows. Nie gwarantujemy, że problemy wynikające z niewłaściwego użycia Edytora rejestru zostaną rozwiązane. Korzystasz z Edytora rejestru na własne ryzyko.

Przed ręcznym przywróceniem Rejestr systemu Windows, musisz utworzyć kopię zapasową, eksportując część rejestru dotyczącą sieci (na przykład Microsoft Windows):

Kliknij przycisk Zaczynać.
Wchodzić " Komenda"V pasek wyszukiwania... NIE NACISKAJ JESZCZE WCHODZIĆ!
Trzymając klucze CTRL-Shift na klawiaturze naciśnij WCHODZIĆ.
Zostanie wyświetlone okno dialogowe dostępu.
Kliknij Tak.
Czarna skrzynka otworzy się z migającym kursorem.
Wchodzić " regedit" i naciśnij WCHODZIĆ.
W Edytorze rejestru wybierz klucz związany z siecią (np. Microsoft Windows), dla którego chcesz utworzyć kopię zapasową.
W menu Plik wybierać Eksport.
Katalogowany Zapisz do wybierz folder, w którym chcesz zapisać kopię zapasową klucza Microsoft Windows.
W polu Nazwa pliku wprowadź nazwę pliku kopii zapasowej, na przykład „Microsoft Windows Backup”.
Upewnij się, że pole Zakres eksportu wybrana wartość Wybrany oddział.
Kliknij Ratować.
Plik zostanie zapisany z rozszerzeniem .reg.
Masz teraz kopię zapasową swoich sieci.

Kolejne kroki ręcznej edycji rejestru nie zostaną omówione w tym artykule, ponieważ mogą one spowodować uszkodzenie systemu. Jeśli chcesz uzyskać więcej informacji na temat ręcznej edycji rejestru, skorzystaj z poniższych łączy.