K-NET s.c.

Portainer – aktualizacja

Portainer to jedna z najlepiej znanych i powszechnie stosowanych platform do wygodnego zarządzania kontenerami Dockera. Zamiast koncentrować się na zapamiętaniu komend linii poleceń możemy przez interfejs graficzny wyklikać praktycznie wszystko. Oczywiście, że zawsze znajdą się zwolennicy „czarnego ekranu”, przyznam że rówież często korzystam z tej metody, ale przy dużej liczbie zarządzanych kontenerów wygodniej jest po prostu skorzystać z przeglądarki.

Od czasu do czasu, w dolnym lewym rogu ekranu powitalnego Portainera pojawia się jednak informacja o dostępności nowej wersji. I w tym przypadku, nie ma już wyjścia, musimy posilić się bezpośrednio terminalem tekstowym. Poniżej zamieściłem podstawowe komendy, których użycie pozwoli zaktualizować Portainer. Oczywiście założyłem, że środowiskiem uruchomieniowym naszego Dockera jest Linux. W moim przypadku, bez wyjątku to któraś wersja pochodna z gałęzi Dabiana. Należy również wspomnieć, że jak będziemy już mieć najnowszy Portainer, to z jego poziomu możemy aktualizować inne kontenery, nie używając linii poleceń.

Zaczynamy od wpisania dwóch poleceń aby zatrzymać i usunąć kontener Portainera:

docker stop portainer
docker rm portainer

Następnie usuwamy obraz Portainera z lokalnego repozytorium:

docker images
docker rmi [IMAGE ID]

Pierwsze polecenie pokaże nam listę wszystkich obrazów. W kolejnym staramy się usunąć wybrany poprzez wskazanie jego ID.

Teraz czas na pobranie najnowszego obrazu Poratinera:

docker pull portainer/portainer-ce

I wreszcie możemy zainstalować nową wersję platformy:

docker run -d -p 8000:8000 -p 9000:9000 —name=portainer /
—restart=always -v /var/run/docker.sock:/var/run/docker.sock /
-v portainer_data:/data portainer/portainer-ce

Dobrze jest pamiętać aby nie zmieniać wartości parametru portainer_data, dzięki czemu nie stracimy ustawień konfiguracyjnych pomiędzy kolejnymi aktualizacjami.

I to wszystko. Teraz można przystąpić do testowania.

MG

Tagi: Docker, linia poleceń, Linux, Portainer, wirtualizacja

Automatyczne rozsyłanie e-maili – Swaks

Automatyczne rozsyłanie e-maili (np. za pomocą opisanego poniżej programu Swaks) z informacjami technicznymi jest chlebem powszednim każdego właściciela serwera. Ponieważ nadzorowanie za pomocą codziennego logowania się i ręcznego przeglądania dzienników systemowych bywa dość żmudną czynnością, stąd każda automatyzacja jest w cenie. Generalnie w systemach linuksowych lokalny serwer SMTP jest na wyposażeniu standardowym. Wysłanie wiadomości z jego pomocą nie stanowi problemu, o ile stosujemy lokalnego klienta. Zresztą wiele usług systemowych właśnie w ten sposób komunikuje się z użytkownikiem. Niemniej czasami potrzebujemy wysłać email na zewnętrzny adres. Poza tym nie zawsze chcemy konfigurować w pełni MTA. Być może łatwiej byłoby użyć jakiegoś kompaktowego narzędzia, które pozwoli z linii poleceń, wygodnie i w prosty sposób przesłać pełnowartościowy email.

Aplikacja Swaks (Swiss Army Knife for SMTP) jest maksymalnie uproszczonym, ale bardzo przydatnym narzędziem wiersza poleceń. Jest ono przede wszystkim używane do testowania serwera SMTP, ale również do wysyłania poczty bezpośrednio „z palca” oraz za pomocą skryptów czy systemowej usługi crone.

Żeby nie zagłębiać się zbytnio w opis wszystkich możliwości Swaks, które zawsze można poznać z pomocą dokumentacji, przejdźmy bezpośrednio do przykładu:

swaks --to odb@mail.org --from "nad@mail.net" /
--server serwer.smtp.net --auth LOGIN --auth-user / 
"nad@poczta.net" --auth-password "P@ssw0rD" / 
-tls --port 587 --header "Subject: [WAZNE] Log systemowy" /
--body /var/log/sys.log

Rozłóżmy powyższą komendę na czynniki pierwsze:

• to – wskazujemy odbiorcę naszej wiadomości,
• from – to adres, który zostać wyświetlony w polu FROM,
• server – serwer SMTP, którego chcesz użyć do wysyłania poczty (np. Gmail),
• auth – rodzaj identyfikacji, jeśli używamy hasła to LOGIN,
• auth-user – nazwa użytkownika na serwerze SMTP,
• auth-password – hasło użytkownika (niestety zapisane jawnym tekstem!),
• tls – włączamy szyfrowanie STARTTLS,
• port – port serwera SMPT, np. 587 czyli Submission,
• header – nagłówek wiadomości, jeśli chcemy dodać temat to użyjemy wyrażenia Subject:,
• body – tutaj może pojawić się tekst lub ścieżka do pliku, który chcemy wczytać.

Celowo pominąłem sposób dodawania załącznika, bo chcę zachęcić do zabawy z narzędziem. Zawsze warto poświęcić 15 minut na testy i przekonać się jak bardzo jest ono wygodne, nawet dla użytkownia z podstawową wiedzą.

MG

Tagi: komendy, linia poleceń, Linux, serwer

Konteneryzacja – error while removing network

Konteneryzacja jest obecnie bardziej modna niż wirtualizacja. Świadomie zaryzykuję takie stwierdzenie choć wiem, że wielu mogłoby się oburzyć. Nie obecnie, tylko od kilku lat, oraz wirtualizacja nadal ma się dobrze. Trzeba jednak przyznać, że lista aplikacji, które zostają zwirtualizowane do formy kontenera np. typu Docker, wydłuża się z każdym rokiem wykładniczo. Dlatego jako fanatyk klasycznej wirtualizacji również musiałem zmierzyć się z tym zagadnieniem. Początki były trudne i nie była to miłość od pierwszego wejrzenia. Jednak z czasem powoli przekonywałem się, chociaż do dzisiaj gnębi mnie myśl o bezpieczeństwie w kontekście aktualizacji gotowych kontenerów dostępnych chociażby przez stronę Docker Hub. Jest to jednak historia na inną opowieść.

Wracając do tematu, skoro przekonałem się do świata kontenerów to zacząłem niemal masowo testować nowe rozwiązania, aplikacje itd. Taki jest los neofity, ale co na to poradzić. Będąc jednocześnie zagorzałym zwolennikiem minimalizmu, wymyśliłem sobie implementację minimalnego serwera w oparciu o Debian Buster (coś w rodzaju bare metal) gdzie jedynym większym softem będzie właśnie paczka docker. W miarę przybywania aplikacji w moim testowym środowisku zacząłem szukać nakładki graficznej do zarządzania. Z pomocą przyszedł pakiet Portainer ze środowiskiem graficznym do zarządzania całą wirtualizacją wraz z prawie jej wszystkimi elementami. Brnąłem dalej. Wiadomo jednak, że im dalej w las tym więcej drzew. Zaczęły się pojawiać problemy. Co gorsza czasami były to w zasadzie dość zasadnicze usterki Dockera. Jedną z nich okazały się hmm… nieścisłości dotyczące definiowania sieci przydzielanych poszczególnym aplikacjom.

Jedną z opcji dostępnych z poziomu Dockera jest tworzenie tzw. macvlan. Jest to sieć kontenerów, które są wystawione poza natowaną warstwą sieciową chronioną przez natywną wirtualizację, co zapewnia oczywiście separowanie aplikacji, a więc odpowiedni poziom bezpieczeństwa, ale uniemożliwia z kolei przydzielanie adresów IP na poziomie równorzędnym z hostem dockera. Czasami potrzebujemy właśnie takiego rozwiązania aby uzyskać efekt podobny do interfejsu typu bridge z klasycznej wirtualizacji (VMware czy KVM). Niestety moim zdaniem obsługa macvlan jest po prostu źle napisana. W wyniku eksperymentowania z sieciami tego typu często dochodzi do sytuacji, w której w systemie pozostają sieci macvlan zachowujące się jak zombie tzn. takie, które do niczego nam się nie przydają (chcieliśmy akurat coś przetestować) a nie można ich usunąć bo otrzymujemy błąd:

„Error response from daemon: error while removing network: configuration network „…. macvlan x.x.x.x” is in use”

W sieci można znaleźć bardzo dużo informacji na ten temat oraz niemal tyle samo propozycji rozwiązania. Ja natomiast chciałem zaproponować jedno z nich, wybrane przeze mnie i myślę, że niezawodne. Zaznaczam od razu, że dotyczy ono hostów typu Linux i wymaga minimalnej znajomości konsoli systemowej. Cały przepis wygląda mniej więcej tak:

• Zaloguj się do swojego hosta za pomocą połączenia SSH.
• Zmień konto na root (o ile już nie zalogowałeś się jako root, ale w tym przypadku poważnie zastanowiłbym się nad zabezpieczeniami Twojego systemu)
• Usuń ręcznie plik local-kv.db

rm /var/lib/docker/network/files/local-kv.db

Tyle w temacie. Rozwiązanie ma tylko taką wadę, że usuwa wszystkie zdefiniowane przez nas sieci ze środowiska konteryzacji. Pozostawia oczywiście tylko te standardowe tj. tworzone na początku instalacji Dockera. Ale porządek na pewno zostanie przywrócony. 🙂

MG

Tagi: Docker, linia poleceń, Linux

Homebrew i problemy z unrar

Jeśli jesteś użytkownikiem MacOS to bardzo prawdopodobne, że już słyszałeś o aplikacji Homebrew. Ten system dystrybucji oprogramowania zastępuje dobrze znane rozwiązania konsolowe z systemów linuksowych. Pozwala dbać o aktualizacje, czyścić system z niepotrzebnych pozostałości po instalacjach itd. W zasadzie można powiedzieć, że dla kogoś kto jest przyzwyczajony do repozytoriów oprogramowania stanowi swoiste narzędzie typu must have dla fanów Apple.

Biorąc pod uwagę bogactwo oprogramowania, które trudno znaleźć w oficjalnych kanałach dystrybucji MacOS Homebrew na pewno jest alternatywą dla osób instalujących takie perełki jak np. Midnight Commander czy ffmpeg. Zazwyczaj instalacja takich aplikacji nie stanowi dla niego większych problemów bo sprowadza się do wpisania jednej linijki z komendą w shellu systemowym.

W codziennej pracy z systemem nieodzowne jest narzędzie to archiwizacji plików. W pracy z MacOS dostępnych jest wiele programów spełniających dobrze te funkcje dla większości otwartych algorytmów jak np. Keka. Co jednak jeżeli otrzymamy pliki spakowane za pomocą RAR. Czy szukać płatnej alternatywy dla jabłuszka? A może po prostu zainstalować unrar za pomocą Homebrew? To ostatnie rozwiązanie powinno wystarczyć, aby okazyjnie poradzić sobie z takim problemem. I rzeczywiście do niedawna wystarczało, bo wspomniany unrar został usunięty z oficjalnych repozytoriów Homebrew.

Aby zaradzić przedstawionym powyżej problemom wystarczy jednak skorzystać z prostej metody korzystając z dodatkowych kanałów dystrybucji. W tym celu używając shella systemowego wpisujemy polecenie:

brew install carlocab/personal/unrar

W ten prosty sposób zainstalujemy unrar i zaoszczędzimy trochę pieniędzy.

MG

Tagi: aplikacje, linia poleceń, macos

Aktualizacja XSIBackup

XSIBackup jako super wygodne narzędzie do wykonywania kopii zapasowych maszyn wirtualnych VMware sprawuje się bez zarzutu. Pisałem o tym programie wielokrotnie np. tutaj. Wspominałem również, że w połączeniu z VMware vCenter Converter Standalone stanowi szwajcarski scyzoryk na wypadek grubszej awarii tj. gdy musimy bardzo szybko odtworzyć wirtualizację np. z powodu awarii sprzętowej hosta.

W przyrodzie nie ma jednak rozwiązań doskonałych i nawet XSIBackup potrafi spłatać figla. Sytuacja, którą chciałem opisać dotyczy momentu tuż po aktualizacji VMware ESXi, kiedy mamy już powgrywane najnowsze patche a jeszcze nie aktualizowaliśmy naszego programu do kopii. Ja po prostu o tym zapomniałem – do tego stopnia, że nawet przeoczyłem brak nowych raportów email o kopiach zapasowych. A program się zwiesił.

Dość szybko znalazłem opis błędu w Internecie, odpowiedzialny był interpreter, a dokładniej jego niezgodność (w nowej wersji VMware) ze starszą wersją XSIBackup. Stanąłem przed koniecznością zainstalowania nowego wydania… i popełniłem duży błąd. Podążając za rozmaitymi poradnikami z forów użytkowników, gdzie twierdzono, że zasadniczo wystarczy podmienić odpowiednie pliki i wszystko powinno działać, pracowicie skopiowałem co trzeba. Zależało mi głównie na tym aby nie tracić tzw. jobs, czyli zadań kopiowania, które zdążyłem skonfigurować (nie jest to trywialna czynność ze względu na mnogość opcji). Zostawiłem całość bez przetestowania – kolejny błąd, a za dwa dni zadzwonił do mnie zaniepokojony użytkownik z informacją, że serwer nie działa. Chodziło o jdną z maszyn wirtualnych. Okazało się, że nie odpowiada cały host VM 🙁 Była sobota i w tym momencie runęła perspektywa wypoczynku. Po dotarciu na miejsce tzn. do serwerowni, ze zdziwieniem stwierdziłem, że serwer działa bez zarzutu, ale interfejsy sieciowe padły. Rzecz jasna restart całej jednostki pomógł, ale zmobilizowało mnie to do wykonania dwóch czynności, które powinienem zrobić od razu.

Po pierwsze usunąłem całą instalację XSIBackup. Polega to głównie na skasowaniu wszystkich plików i co ważne usunięciu zadań kopiowania na poziomie cron:

rm -rf "/vmfs/volumes/datastore1/xsi-dir"; \ 
chmod 0700 /var/spool/cron/crontabs/root; \ 
sed -i '/-dir\/jobs/d' /var/spool/cron/crontabs/root; \ 
sed -i '/cron-init/d' /etc/rc.local.d/local.sh

Po drugie zainstalowałem od nowa XSIBackup odtwarzając skopiowane wcześniej zadania automatycznego wykonywania kopii. Na szczęście pomogło.

MG

Tagi: ESXi, linia poleceń, Linux, serwer, VMWare

Zewnętrzny numer IP?

Numer IP – bardzo często bywa tak, że z jakichś powodów chcielibyśmy uzyskać informację na ten temat (zwłaszcza jeśli chodzi o zewnętrzny numer IP). Jak zauważyłem problem ten dotyczy nie tylko sytuacji, w której po prostu sprawdzamy czy operator przydzielił nam właściwy adres IP, ale również coraz częściej jeśli chcemy np. sprawdzić czy zadziałało połączenie prywatne VPN. Zauważyłem, że powoli stają się one standardem (i bardzo dobrze), warto zatem czasami upewnić się, że nasz ruch przechodzi przez odpowiedni router.

Do tej pory można to było zrobić na kilka, mniej lub bardziej eleganckich sposobów. Dla mniej wprawnych zawsze pozostaje np. serwis https://www.whatismyip.com. Ta metoda wymaga jednak posiadania interfejsu graficznego czyli GUI. A jak zrobić to samo na serwerze, który posiada tylko czystą konsolę tekstową?

Tutaj również mamy do dyspozycji wiele metod. Szczególnie jeżeli używamy mojego ulubionego rozwiązania czyli Linuxa. Od lat korzystałem w tym celu z dobrze znanego polecenia wget, które pozwala na sparsowanie wyjścia i tą nieco pokrętną metodą uzyskanie odpowiedzi na pytanie postawione w tytule artykułu:

/usr/local/bin/wget -qO - http://ipinfo.io/ip

Świat idzie jednak do przodu (i bardzo dobrze). wget powoli jest zastępowany przez nowe polecenie (a w zasadzie rozbudowane narzędzie) czyli curl. W takim wydaniu uzyskanie informacji jaki jest zewnętrzny numer IP jest jeszcze prostsze:

curl http://icanhazip.com

I o to przecież wszystkim chodzi 🙂

MG

Tagi: komendy, konfiguracja, linia poleceń, Linux

Karta SD – formatowanie w Mac OS

Karta SD i jej formatowanie w Mac OS może być źródłem problemów. Sam kilka razy miałem kłopoty. Oczywiście jeśli stosujemy standardowe rozwiązania i mamy kartę sformatowaną dla systemu MS-DOS (FAT), tudzież dla typowego Mac OS Extended (Journaled) to raczej nie napotkamy na żadne przeszkody. Czasami jednak, zwłaszcza gdy zamierzamy testować np. Raspberry Pi, musimy zmierzyć się z innymi systemami plików. I nie chodzi w tym przypadku o zakładanie i konfigurowanie tychże, ale o przygotowanie karty do pracy, czyli usunięcie w pierwszym kroku wszystkich partycji z dostępnej przestrzeni. Niestety, bez tego często nie jesteśmy w stanie korzystać z SD. Wiem, że brzmi to co najmniej dziwnie, ale sam miałem takie problemy.

Jak sprawdziłem najszybszą niezawodną metodą jest skorzystanie z wbudowanych narzędzi systemowych. A więc czas uruchomić terminal. 😉

Jednym z najbardziej pożytecznych i skutecznych narzędzi jest diskutil. Program ten pozwoli nam na wyświetlenie zawartości karty SD:

$ diskutil list

Otrzymamy nazwy urządzeń (np. disk2 lub disk3) z przypisanymi partycjami. Z wyświetlonych informacji można łatwo wywnioskować, które urządzenie to karta SD. Zakładając, że jest np. disk2, możemy przygotować kartę do pracy z Raspberry Pi:

$ diskutil eraseDisk FAT32 RASPBIAN MBRFormat disk2

Na tym jednak nie koniec. Wracając do głównego wątku, możemy również dosłownie wyzerować kartę SD. W tym celu najpierw powinniśmy odmontować urządzenie:

$ diskutil unmountDisk disk2

A potem usunąć jej zawartość:

$ diskutil zeroDisk disk2

Lub inną metodą:

$ diskutil randomDisk disk2

Warto wspomnieć, że opisana komenda sprawdza się również w przypadku pamięci USB, dysków twardych itd. Trzeba jej jednak używać bardzo ostrożnie, i chyba nie muszę tłumaczyć dlaczego.

To tyle w tym ostatnim tegorocznym wpisie.

MG

Tagi: komendy, linia poleceń, Mac OS

OpenVAS – testy penetracyjne

W dzisiejszych czasach wykonywanie testów penetracyjnych jest, lub przynajmniej powinno być, elementarzem każdego administratora, który zarządza siecią z serwerami obsługiwanymi przez innych użytkowników. Doświadczenie uczy, że pomysłowość ludzka polegająca m. in. na pozostawianiu niezabezpieczonych usług, skonfigurowanych niepoprawnie aplikacji itp. jest praktycznie nieograniczona. Niestety sieć jest tak bezpieczna jak jej nasłabszy punkt. Dlatego chciałem napisać parę słów o dosyć popularnym i prostym w obsłudze narzędziu jakim jest OpenVAS.

Większość popularnych dystrybucji Linuxa posiada gotowe paczki do instalacji. W Debianie 10 Buster (jak do tej pory ostatnim) nie trzeba nawet wspomagać się dodatkowymi bibliotekami, wystarczy wydać polecenie:

apt-get install openvas -y

Po kilku lub kilkunastu minutach, w zależności od stanu łacza internetowego, cały pakiet zostanie zainstalowany i można przejść do jego konfiguracji:

openvas setup

Aplikacja rozpocznie pobieranie aktualizacji z 3 źródeł – NVT, Cert Data i SCAP Data, tak abyśmy mieli dostęp to świeżego zestawu testów, czyli tak naprawdę np. najnowszych definicji dotyczących exploitów, opisanych zagrożeń itp. Całość trochę potrwa i na koniec zostaniemy poinformowani o sukcesie (mam nadzieję) oraz co najważniejsze wyświetlone zostanie hasło dla administratora usługi. Hasło w zasadzie jest jednorazowe i należy je zmienić od razu po pierwszym zalogowaniu, tym bardziej, że nie jest wygodne do zapamiętania.

OpenVAS jest obsługiwany za pomocą przeglądarki internetowej. Domyślnie skonfigurowany jest tylko dostęp lokalny. Może to stanowić pewne utrudnienie, szczególnie w sytuacji gdy korzystamy z serwera bez środowiska graficznego. Dlatego powinniśmy sprawdzić adres IP swojego serwera:

ip a

Następnie trzeba wedytować 2 pliki konfiguracyjne:

/lib/systemd/system/greenbone-security-assistant.service
/lib/systemd/system/openvas-manager.service

i zmienić adres '127.0.0.1′ na uzyskany adres naszego serwera – w każdym miejscu, w którym występuje.

Na koniec pozostaje uruchomić ponownie usługę OpenVAS:

systemctl daemon-reload 
openvas-stop 
openvas-start

Od tej chwili możemy cieszyć się w pełni funkcjonalnym skanerem sieci do celów testów penetracyjnych. Otwieramy przeglądarkę i podajemy adres:

https://adres_ip_serwera:9392

MG

Tagi: Debian, konfiguracja, linia poleceń, Linux, serwer

Telnet w Windows czyli wakacje 2019

Po raz pierwszy od 3 miesięcy postanowiłem napisać krótki wakacyjny wpis jako podsumowanie letniego okresu. Chociaż podsumowanie nie będzie tu najlepszym określeniem. Chciałem po prostu zamieścić przynajmniej jeden wpis podczas wakacji 2019 (np. dotyczący popularnej komendy telnet).

Ponieważ nie można tak od razu rzucić się na pracę, tym razem kilka krótkich akapitów o narzędziu telnet. Już ponad 20 lat używam go w codziennej pracy. Powszechnie wiadomo – jest niebezpieczne, powinniśmy go unikać jak tylko można, ale w zasadzie do sprawdzania otwartych portów na zdalnych hostach jest najszybsze. Zapewne większość administratorów używała nie raz polecenia:

telnet host.remote.net 80

żeby sprawdzić czy działa serwer stron www. Komenda ta zadziała nawet jeżeli firewall blokuje pakiety ICMP czyli jeżeli w wyniku:

ping host.remote.net

otrzymamy odpowiedź typu „host jest nieosiągalny”.

W najnowszych wersjach systemów Windows a dotyczy to zarówno stacji roboczych jak i serwerów, ze wspomnianych względów bezpieczeństwa nie ma już komendy telnet. Można ją oczywiście różnymi sposobami doinstalować, jest nawet całkiem sporo poradników typu how-to w sieci. Jednak skoro Microsoft zadecydował, że coś jest niebezpieczne to może znajdzie się alternatywa.

Okazuje się, że wraz z rozwojem środowiska PowerShell, Microsoft dorzuca nam z każdą wersją ciekawe narzędzia. Jednym z nich jest program Test-NetworkConnection. Jeżeli uruchomimy PowerShell w naszym systemie to całkiem spokojnie możemy go wypróbować. A ponieważ parę akapitów wcześniej wspominałem o telnet, to spróbujmy użyć TNC właśnie w taki sposób:

tnc host.remote.net -port 80

Wynikiem będzie raport z ostanią linijką zatytułowaną TcpTestSucceeded. Parametr ten przyjmuje wartości true/false i funkcjonalnie odpowiada staremu dobremu połączeniu za pomocą telnet. TNC ma oczywiście multum innych opcji i serdecznie zachęcam do zapoznania się z dokumentacją.

MG

Tagi: komendy, linia poleceń, Windows

IPv6 w służbie udziałom sieciowym

Życie lubi często płatać figle. Nierzadko stawia administratorów przed bardzo dziwnymi zadaniami, uwzględniającymi bardzo wydumane ezoteryczne scenariusze działania. Gdybym sam się z tym nie stykał na co dzień, to muszę przyznać, że byłoby mi ciężko uwierzyć. A jednak shit happens jak mawiają.

Dzisiejszy wpis dotyczy sytuacji, w której ktoś postanowił wymienić sprzęt sieciowy, w tym serwery plików NAS (tj. QNAP, Synology) i zastąpić je po prostu udziałami na serwerze plików Windows. Ponieważ nowa polityka bezpiczeństwa nie zakładała wykorzystywania rozwiązań innych niż z systemem Windows, nagle wspomniane wcześniej urządzenia zostały wyłączone. Można powiedzieć – cóż… koszty wdrożenia… ale w ten sposób pozbyto się niemałej przestrzeni dyskowej (chodziło to o kilka, kilkanaście TB), która może być zawsze wykorzystana np. do kopii zapasowych. Nietrudno się domyśleć, że powstał problem jak podłączyć z powrotem urządzenia tak aby nie naruszały zasad bezpieczeństwa. Najlepiej oczywiście lokalnie np. przez port USB, ale po pierwsze nie każde ma taką możliwość, po drugie tracimy w ten sposób masę funkcji, które są wbudowane w gotowce typu NAS. Czyli pozostaje przełożyć dyski do serwerów Windows… otóż nie do końca.

Pierwszą myślą było utworzenie osobnej podsieci lokalnej dla naszego NASa i przygotowanie na wybranym komputerze sieciowego interfejsu wirtualnego tak aby stacja mogła korzystać równocześnie z głównej podsieci i w połączeniu punkt-punkt z dysków NAS (dzięki udziałom SMB). Łatwo powiedzieć i łatwo zrobić jeśli ktoś nie rzuca kłód pod nogi. A tym razem kolejną przeszkodą był fakt, że główny interfejs sieciowy został skonfigurowany do pobierania parametrów IP przez DHCP. Niestety ani Windows 7 ani Windows 10 nie umożliwiają skonfigurowania wirtualnej karty sieciowej jeśli podstawowa korzysta z DHCP. Oczywiście w sieci można znaleźć trochę propozycji rozwiązań, jednak nie działają one wogóle, albo wymagają instalowania dodatkowego oprogramowania. Dodatkowo często po restarcie komputera cała misternie przygotowana konfiguracja idzie w cyfrową niepamięć. I właśnie w tym przypadku przydaje się IPv6.

Wystarczy otworzyć okno właściwości karty sieciowej, żeby zauważyć, że przecież oporócz IPv4 możemy skonfigurować IPv6. Na razie mało kto z tego korzysta, a bywa, że ze względów bezpieczeństwa IPv6 jest wyłączane. Tym razem możemy skonfigurować lokalną sieć IPv6 do połączenia naszego komputera z NASem. Zatem po kolei. Na komputerze Windows dodajemy IPv6 z adresem lokalnym:

fe80::208:9bff:fef9:44f

Lokalny adres IPv6 wygenerujemy przy pomocy strony https://www.ultratools.com/tools/rangeGenerator. Pamiętajmy jednak aby wybrać adres z prefiksem 64. Jest to dosyć często spotykana opcja w gotowcach typu NAS.

Na naszym urządzeniu NAS konfigurujemy IPv6 z tej samej podsieci ale np. z numerem o 1 większym. Czyli uruchamiamy kalkulator z możliwością obliczeń w zapisie szesnastkowym i do wartości 44f dodajemy 1. Powiniśmy otrzymać adres postaci:

fe80::208:9bff:fef9:450

Po restarcie obu urządzeń mamy gotową podsieć lokalną składającą się z komputera Windows i serwera NAS. Musimy tylko wiedzieć jak dostać się do dysków np. z poziomu Eksploratora Plików Windows. Otwieramy zatem eksplorator i w polu adresu wpisujemy:

\\fe80--208-9bff-fef9-450.ipv6-literal.net

Wpisywanie każdorazowo powyższego adresu jest kłopotliwe, można zatem przygotować skrót na Pulpicie albo (jeszcze lepiej) zamontować nasz udział jako lokalny katalog (C:\NAS):

mklink /D C:\NAS \\fe80--208-9bff-fef9-450.ipv6-literal.net\

Pamiętajmy jednak, że montować możemy udział sieciowy (np. \\fe80–208-9bff-fef9-450.ipv6-literal.net\kopie), więc podany przeze mnie przykład nie zadziała 😉 .

MG

 

Tagi: konfiguracja, linia poleceń, NAS, urządzenia, Windows