Laboratorium: Wirtualne Sieci Prywatne (VPN)

Część 1 Definicja VPN, Część 5 Routing w tunelach, Point-to-Point.

Firma planuje połączyć dwa odległe biura w jedną strukturę sieciową, ale zanim przystąpi do wdrażania tuneli, musi zapewnić pełną widoczność między interfejsami zewnętrznymi routerów. Obecnie routery w obu lokalizacjach mają skonfigurowane adresy IP na interfejsach WAN, ale nie potrafią się ze sobą komunikować przez symulowaną sieć dostawcy (ISP). Twoim zadaniem jest poprawne skonfigurowanie routingu statycznego w taki sposób, aby routery "widziały" swoje zewnętrzne adresy. Jest to krytyczny etap przygotowawczy, bez którego zestawienie jakiegokolwiek tunelu VPN nie będzie możliwe. Musisz udowodnić stabilność połączenia przed przejściem do etapów szyfrowania.

• ✓Użycie dwóch routerów serii 2911 jako bram VPN dla Oddziału A i Oddziału B.
• ✓Dodanie trzeciego routera symulującego chmurę ISP w środku topologii.
• ✓Adresacja zewnętrzna: 203.0.113.1/30 (Oddział A) oraz 198.51.100.1/30 (Oddział B).
• ✓Konfiguracja podsieci LAN dla każdego z oddziałów: 172.16.1.0/24 i 172.16.2.0/24.
• ✓Ustawienie routingu statycznego na routerach brzegowych (brama domyślna na ISP).
• ✓Konfiguracja routera ISP tak, aby znał drogi do publicznych końcówek routerów firmowych.
• ✓Weryfikacja dostępności publicznych adresów IP za pomocą polecenia ping z routera na router.
• ✓Użycie polecenia traceroute do udokumentowania ścieżki pakietu.
• ✓Zapewnienie poprawnego opisu interfejsów (description) dla czytelności konfiguracji.
• ✓Zabezpieczenie routerów podstawowym hasłem do trybu uprzywilejowanego.
• ✓Sprawdzenie tablicy routingu (show ip route) na wszystkich trzech urządzeniach.
• ✓Weryfikacja braku komunikacji między sieciami LAN przed zestawieniem VPN.

• ✓Routing statyczny stanowi fundament (podstawa) dla każdego tunelu VPN — bez poprawnej łączności między publicznymi adresami IP routerów, zestawienie tunelu jest niemożliwe.
• ✓Internet nie przekazuje pakietów z prywatnymi adresami RFC 1918 (np. 172.16.x.x, 10.x.x.x, 192.168.x.x) — routery ISP ignorują takie pakiety zgodnie z zasadą hierarchiczności routingu.
• ✓Tunel VPN tworzy wirtualny "most" między sieciami LAN, opakowując pakiety w nowy nagłówek z publicznymi adresami IP — umożliwia ich transmisję przez Internet.
• ✓NAT (Network Address Translation) może zastąpić VPN dla pojedynczych hostów, ale nie zapewnia pełnej łączności między sieciami LAN bez dodatkowych mechanizmów.
• ✓Routing statyczny jest niezbędny do wskazania "następnego skoku" dla ruchu kierowanego przez tunel VPN — bez niego router nie wie, gdzie wysłać pakiety.
• ✓Trasa domyślna (0.0.0.0/0) wskazująca na ISP umożliwia komunikację z Internetem, ale ruch VPN musi mieć jawnie zdefiniowane trasy lub być przekierowany przez interfejs tunelowy.
• ✓Weryfikacja łączności między publicznymi IP (ping przez ISP) jest krytycznym krokiem przed konfiguracją VPN — eliminuje problemy warstwy 3 przed przejściem do warstwy aplikacji tunelowania.
• ✓Podsumowanie: routing statyczny to "drogi" a VPN to "pojazd" — bez dróg nie ma możliwości jazdy, bez tunelu pojazd nie dotrze do celu przez Internet.

Część 2 Protokół GRE, Enkapsulacja, Część 5 Point-to-Point interfaces.

Centrala firmy w Warszawie potrzebuje przesyłać ruch multicastowy oraz inne protokoły nie-IP do oddziału w Krakowie. Klasyczny VPN bazujący wyłącznie na politykach IPSec nie wspiera bezpośrednio takich wymagań. Zdecydowano o wdrożeniu tunelu GRE, który stworzy wirtualny interfejs punkt-punkt między routerami. Jako administrator musisz skonfigurować ten tunel, nadając mu dedykowaną adresację wewnętrzną. Musisz zapewnić, aby pakiety z sieci LAN Oddziału A mogły trafiać do Oddziału B poprzez nowo utworzony interfejs wirtualny Tunnel0. Pamiętaj, że na tym etapie ruch nie jest jeszcze szyfrowany.

• ✓Utworzenie interfejsu wirtualnego "interface Tunnel0" na obu routerach brzegowych.
• ✓Nadanie adresacji IP dla tunelu: 10.255.255.1/30 (A) oraz 10.255.255.2/30 (B).
• ✓Wskazanie adresu źródłowego tunelu (tunnel source) jako interfejs zewnętrzny WAN.
• ✓Wskazanie adresu docelowego tunelu (tunnel destination) jako publiczne IP drugiego routera.
• ✓Ustawienie trybu tunelu na "tunnel mode gre ip".
• ✓Weryfikacja statusu interfejsu tunelu (up/up) poleceniem show ip interface brief.
• ✓Dodanie tras statycznych dla sieci LAN wskazujących na adres IP drugiego końca tunelu.
• ✓Weryfikacja łączności między komputerami w sieciach LAN za pomocą ping.
• ✓Użycie polecenia traceroute, aby potwierdzić przejście pakietu przez adresy 10.255.255.x.
• ✓Analiza nagłówka GRE w pakiecie za pomocą trybu symulacji (PDU detail).
• ✓Dokumentacja narzutu (overhead) jaki dodaje GRE do oryginalnego pakietu IP.
• ✓Sprawdzenie MTU interfejsu tunelu i porównanie go z interfejsem fizycznym.

• ✓Enkapsulacja GRE dodaje nowy nagłówek IP (z publicznymi adresami źródła i celu) wokół oryginalnego pakietu — struktura: [IP_out][GRE][IP_in][dane].
• ✓GRE obsługuje wiele protokołów warstwy 3 (nie tylko IP), co czyni go uniwersalnym protokołem tunelowym dla heterogenicznych środowisk.
• ✓Kluczowa wada GRE: brak szyfrowania — dane w publicznym Internecie są przesyłane jako jawny tekst, każdy może je przechwycić i odczytać.
• ✓Pakiety GRE nie mają uwierzytelniania — atakujący może wstrzyknąć fałszywe pakiety GRE do tunelu bez wykrycia.
• ✓GRE zwiększa narzut (overhead) o ok. 24 bajty na pakiet — wymaga dostosowania MTU (np. do 1400) aby uniknąć fragmentacji.
• ✓GRE jest bezstanowy — nie ma mechanizmu potwierdzenia odebrania pakietów, co może powodować utratę danych bez powiadomienia.
• ✓Tunel GRE tworzy wirtualny interfejs Layer 3 — umożliwia running protokołów routingu (OSPF, EIGRP) przez tunel, czego nie obsługuje czyste IPSec w trybie Tunnel.
• ✓Podsumowanie: GRE to doskonały mechanizm do łączenia sieci i przesyłania multicastów, ale NIE zapewnia poufności — wymaga połączenia z IPSec (GRE over IPSec).

Część 3 IPSec, IKEv1/IKEv2, ISAKMP, Diffie-Hellman, AES/SHA.

Po udanych testach przesyłu danych firma wymaga teraz zapewnienia pełnej poufności i integralności danych przesyłanych między biurami. Twoim zadaniem jest rezygnacja z nieszyfrowanego GRE na rzecz tunelu IPSec w trybie Site-to-Site (łączącego oddziały). Musisz skonfigurować obie fazy negocjacji IKE: fazę 1 (ISAKMP) dla bezpiecznego kanału sterowania oraz fazę 2 (IPSec) dla szyfrowania danych użytkownika. Wykorzystaj listy kontroli dostępu (ACL) do zdefiniowania "ruchu interesującego", który ma zostać zaszyfrowany. Sukcesem będzie udokumentowanie, że pakiety przesyłane przez ISP są całkowicie nieczytelne (zaszyfrowane protokołem ESP).

• ✓Konfiguracja polityki ISAKMP (Phase 1): AES-256, SHA-256, Group 2 (DH), Pre-shared Key.
• ✓Ustawienie wspólnego klucza (key) dla IP drugiego routera.
• ✓Konfiguracja transform-set (Phase 2) z użyciem esp-aes i esp-sha-hmac.
• ✓Stworzenie ACL (np. 101) definiującej ruch między LAN A a LAN B.
• ✓Konfiguracja "crypto map" łączącej ACL, transform-set i peer IP.
• ✓Przypisanie mapy krypto do interfejsu zewnętrznego WAN (crypto map nazwa).
• ✓Inicjacja ruchu tunelowego poprzez ping między hostami LAN.
• ✓Weryfikacja sesji ISAKMP poleceniem show crypto isakmp sa.
• ✓Weryfikacja tuneli IPSec poleceniem show crypto ipsec sa (liczba pakietów pkts encap/decap).
• ✓Analiza pakietu ESP w trybie symulacji - sprawdzenie czy zawartość IP jest ukryta.
• ✓Ustawienie czasu życia kluczy (lifetime) zgodnie z polityką bezpieczeństwa.
• ✓Zapewnienie spójności parametrów po obu stronach (najczęstszy punkt awarii).

• ✓Szyfrowanie (encryption) chroni poufność danych — przekształca jawny tekst w szyfrogram nieczytelny dla osób nieposiadających klucza (AES, 3DES).
• ✓Uwierzytelnianie (authentication) potwierdza tożsamość stron — gwarantuje, że komunikujesz się z prawdziwym partnerem, nie z atakującym (pre-shared keys, certyfikaty).
• ✓IPSec ESP zapewnia oba: szyfrowanie ( confidentiality) i opcjonalnie uwierzytelnianie ( integrity) poprzez HMAC.
• ✓Diffie-Hellman (DH) umożliwia wymianę kluczy przez niezaufane medium bez przesyłania sekretu — obie strony wyliczają wspólny klucz z publicznych wartości.
• ✓Grupa DH określa siłę klucza: Grupa 1 (768 bitów) — słaby, Grupa 2 (1024 bity) — minimalny, Grupa 5 (1536 bitów) lub wyższy — zalecany dla produkcji.
• ✓Wymiana kluczy DH jest podstawą fazy 1 (ISAKMP) — ustanawia bezpieczny kanał do negocjacji kluczy fazy 2 (IPSec SA).
• ✓IPSec w trybie Tunnel szyfruje cały oryginalny pakiet IP, tworząc nowy nagłówek — idealny dla Site-to-Site VPN.
• ✓Podsumowanie: IPSec łączy szyfrowanie (ochrona danych) z uwierzytelnianiem (ochrona przed atakami man-in-the-middle), a DH umożliwia bezpieczną wymianę kluczy przez Internet.

Część 2 GRE, Część 3 IPSec Transport Mode, Część 5 Routing w tunelu.

Firma zdecydowała się na połączenie zalet obu rozwiązań: elastyczności GRE (obsługa multicastów i routowania) oraz bezpieczeństwa IPSec. Jest to najczęściej stosowany model w profesjonalnych sieciach korporacyjnych. Twoim zadaniem jest "opakowanie" wcześniej skonfigurowanego tunelu GRE w ochronę IPSec. Zamiast szyfrować bezpośrednio ruch między sieciami LAN, zaszyfrujesz same pakiety GRE podróżujące między zewnętrznymi adresami routerów. Dzięki temu wirtualny interfejs Tunnel0 stanie się bezpiecznym kanałem komunikacyjnym, przez który w przyszłości przepuścisz routery dynamiczne.

• ✓Utrzymanie konfiguracji interfejsu Tunnel0 z Zadania 02.
• ✓Modyfikacja transform-set IPSec do pracy w trybie "mode transport" (opcjonalne, ale zalecane dla GRE).
• ✓Modyfikacja ACL krypto: ma teraz pasować wyłącznie do ruchu protokołu GRE (proto 47) między IP routerów.
• ✓Aktualizacja crypto map i ponowne przypisanie do interfejsu WAN.
• ✓Weryfikacja, czy tunel GRE nadal przekazuje ruch LAN (ping między komputerami).
• ✓Weryfikacja w show crypto ipsec sa, czy pakiety GRE są szyfrowane przez IPSec.
• ✓Analiza podwójnej enkapsulacji pakietu (IP -> GRE -> ESP -> IP).
• ✓Udokumentowanie wzrostu MTU/MSS wynikających z wielu nagłówków.
• ✓Sprawdzenie statusu interfejsu tunelu przy wyłączonym/włączonym krypto.
• ✓Konfiguracja parametrów IKE Phase 1 dla silnej odporności na ataki brute-force.
• ✓Weryfikacja poprawności routingu statycznego przez interfejs tunelowy.
• ✓Zastosowanie opisu (description) informującego o szyfrowaniu na interfejsie Tunnel0.

• ✓GRE over IPSec łączy zalety obu technologii: elastyczność GRE (multicast, rutowanie, wiele protokołów) + bezpieczeństwo IPSec (szyfrowanie, uwierzytelnianie).
• ✓Czysty IPSec w trybie Tunnel nie obsługuje multicastów — nie można przez niego uruchomić protokołów routingu (OSPF, EIGRP) bez dodatkowych mechanizmów.
• ✓GRE over IPSec w trybie transportowym zmniejsza narzut — szyfruje tylko ładunek GRE, nie zewnętrzny nagłówek IP.
• ✓Problem z fragmentacją: podwójna enkapsulacja (IP -> GRE -> ESP -> IP) zwiększa rozmiar pakietu o 50-70 bajtów, co może przekroczyć MTU łącza ISP.
• ✓Fragmentacja negatywnie wpływa na wydajność — każdy fragment musi być osobno szyfrowany/deszyfrowany, zwiększa opóźnienia i obciążenie CPU routera.
• ✓Rozwiązanie: zmniejszenie MTU tunelu do 1400 bajtów + MSS Clamping (ip tcp adjust-mss 1360) na interfejsie tunelowym.
• ✓Tryb transportowy GRE over IPSec jest preferowany gdy tunel łączy dwa konkretne routery — mniejszy narzut niż tryb tunelowy.
• ✓Podsumowanie: GRE over IPSec to powszechnie stosowany standard dla korporacyjnych sieci VPN — umożliwia dynamiczny routing przez szyfrowany tunel.

Część 5 OSPF w tunelach, Multicast w VPN, Network Type.

Sieć firmowa rozrosła się o wiele nowych podsieci VLAN w obu lokalizacjach. Ręczne dopisywanie tras statycznych w miarę rozwoju firmy staje się nieefektywne i generuje ryzyko błędów. Jako administrator musisz uruchomić protokół OSPF na interfejsach tunelowych GRE over IPSec zestawiając sąsiedztwo między routerami w różnych miastach. Routery powinny automatycznie wymieniać się informacjami o wszystkich podsieciach LAN podpiętych bezpośrednio do nich. Dzięki tunelowi GRE, pakiety Hello protokołu OSPF (multicast) zostaną bezpiecznie przesłane do oddziału.

• ✓Usunięcie wszystkich tras statycznych dotyczących sieci LAN z routerów.
• ✓Konfiguracja procesu "router ospf 1" na obu routerach brzegowych.
• ✓Ustawienie ID routera (router-id) dla czytelności.
• ✓Dodanie sieci tunelu (10.255.255.0/30) do obszaru Area 0 (sieć szkieletowa).
• ✓Dodanie lokalnych sieci LAN do procesu OSPF (network command).
• ✓Konfiguracja interfejsu tunelu jako "ip ospf network point-to-point" (przyspieszenie zbieżności).
• ✓Weryfikacja ustanowienia sąsiedztwa poleceniem show ip ospf neighbor (stan FULL).
• ✓Sprawdzenie tablicy routingu (show ip route ospf) i obecności tras oznaczonych flagą 'O'.
• ✓Weryfikacja łączności między hostami LAN przy użyciu tras dynamicznych.
• ✓Test symulacji awarii tunelu (shutdown interfejsu) i obserwacja reakcji OSPF.
• ✓Analiza kosztu trasy (metric) przesyłanej przez tunel.
• ✓Udokumentowanie wysyłanych pakietów Hello przelatujących przez tunel krypto.

• ✓OSPF używa multicastu (224.0.0.5 dla routerów DR, 224.0.0.6 dla Designated Router) do odkrywania sąsiadów i rozsyłania LSA.
• ✓Czysty IPSec w trybie Tunnel nie obsługuje multicastów — pakiety multicastowe nie są szyfrowane przez IPSec, co uniemożliwia działanie OSPF.
• ✓GRE over IPSec rozwiązuje problem — enkapsulacja GRE przenosi pakiety multicastowe przez zaszyfrowany tunel IPSec.
• ✓Proces zbieżności sieci: gdy nowa podsieć LAN zostaje dodana, router generuje LSA typu 1 (LSA routera), wysyła przez multicast, sąsiedzi rozsyłają dalej.
• ✓Czas zbieżności zależy od parametrów Hello/Dead interval — domyślnie LSA jest flooded co 30 minut (LS refresh), ale zmiany propagują się w sekundach.
• ✓OSPF w trybie point-to-point na interfejsie tunelowym eliminuje wybór DR/BDR — oba routery ustanawiają bezpośrednie sąsiedztwo (FULL state).
• ✓Metryki OSPF przez VPN mogą być statyczne lub dynamiczne — zalecane jest użycie kosztu interfejsu tunelowego zgodnie z przepustowością łączy.
• ✓Podsumowanie: OSPF przez VPN wymaga GRE (lub innego tunelu obsługującego multicast) — czysty IPSec nie zapewnia tej funkcjonalności.

Część 1 VPN dla pracowników zdalnych (Road Warrior), Część 7 Bezpieczeństwo haseł, wieloskładnikowe uwierzytelnianie (MFA) w teorii.

Z powodu przejścia na model pracy hybrydowej, firma potrzebuje bezpiecznego dostępu zdalnego do zasobów biurowych z mniejszego oddziału (filii). Oddział ten nie posiada profesjonalnego routera VPN, a jedynie prosty router 1841 z dostępem do Internetu. Jako inżynier sieciowy musisz skonfigurować bramę VPN w Centrali, aby akceptowała połączenia od tego oddziału wykorzystując prosty router jako klienta IPSec VPN (Easy VPN Remote). Wykorzystaj mechanizm IPSec Site-to-Site z dynamicznym mapowaniem — jest to najprostszy sposób na Remote Access w Packet Tracer. Musisz stworzyć profil użytkownika i zapewnić dynamiczne przydzielanie adresów IP z wewnętrznej puli firmowej.

• ✓Konfiguracja puli adresów IP (ip local pool) dla oddziału.
• ✓Stworzenie lokalnej bazy użytkowników (username/password) na routerze Centrali.
• ✓Konfiguracja serwera VPN (crypto map z dynamic-map) na interfejsie zewnętrznym Centrali.
• ✓Ustawienie parametrów uwierzytelniania i szyfrowania (transform-set).
• ✓Podłączenie routera oddziału do "Internetu" przez osobny router/switch.
• ✓Konfiguracja klienta IPSec na routerze oddziału (prosty crypto map).
• ✓Ustanowienie połączenia i weryfikacja otrzymanego adresu IP z puli.
• ✓Weryfikacja dostępu do serwera plików w Centrali.
• ✓Sprawdzenie statusu aktywnych sesji (show crypto isakmp sa).
• ✓Analiza routingu po stronie oddziału (trasa do sieci LAN Centrali).
• ✓Zabezpieczenie serwera przed atakami brute-force (limity w ACL).
• ✓Ustalenie polityki silnych haseł dla kont dostępu.

• ✓Road Warrior (zdalny pracownik) łączy się z firmową siecią z dowolnego miejsca (dom, hot spot WiFi, lotnisko) — zwiększa to powierzchnię ataku.
• ✓Split Tunneling umożliwia użytkownikowi jednoczesne używanie tunelu VPN do firmy I lokalnego Internetu — ryzykowne, bo ruch nieVPN może ominąć zabezpieczenia firmowe.
• ✓Zagrożenia Split Tunneling: atakujący w tej samej sieci WiFi może przechwycić ruch, zainfekowany komputer może stać się wektor ataku na sieć firmową.
• ✓Zalecana konfiguracja: blokada Split Tunneling — cały ruch (w tym do Internetu) musi iść przez tunel VPN, co wymusza corporate policy na urządzeniu klienta.
• ✓Uwierzytelnianie hasłem (pre-shared key) jest podatne na ataki słownikowe i brute-force — wymaga silnych, skomplikowanych haseł i regularnej zmiany.
• ✓Certyfikaty cyfrowe zapewniają silniejsze uwierzytelnianie — oparte na kryptografii asymetrycznej, nie można ich "odgadnąć" jak hasła.
• ✓PKI (Public Key Infrastructure) z certyfikatami umożliwia łatwe unieważnienie (revocation) kompromitowanych certyfikatów przez CRL lub OCSP.
• ✓Podsumowanie: Remote Access VPN jest wygodny, ale wymaga restrykcyjnych zasad (blokada Split Tunneling, certyfikaty zamiast haseł) dla bezpieczeństwa produkcyjnego.

Część 6 VLAN przez tunel, L2 VPN, EoIP (teoria), Bridge Over VPN.

Firma zdecydowała, że nie cały ruch z oddziału powinien być traktowany tak samo. Musisz zapewnić osobny kanał komunikacji dla działu księgowości (VLAN 10) oraz działu technicznego (VLAN 20), tak aby urządzenia z tych działów mogły komunikować się ze swoimi odpowiednikami w centrali, pozostając w izolacji od siebie. Zrealizujesz to zadanie poprzez konfigurację VLANów na przełącznikach oraz subinterfejsów routowanych (Router-on-a-Stick) na routerze oddziału i centrali. Ruch z każdego VLAN będzie routowany przez ten sam tunel GRE/IPSec, ale logicznie izolowany na warstwie 3. Musisz udowodnić, że ruch z VLANu 10 w oddziale trafia wyłącznie do VLANu 10 w centrali i nie może komunikować się z VLAN 20.

• ✓Konfiguracja dwóch VLANów (10 i 20) na przełącznikach w obu lokalizacjach.
• ✓Konfiguracja routerów w trybie "Router-on-a-Stick" z subinterfejsami na interfejsie LAN.
• ✓Utworzenie jednego tunelu GRE (podstawowego z Zadania 02).
• ✓Zabezpieczenie tunelu GRE przez IPSec (jak w Zadaniu 04).
• ✓Konfiguracja routingu statycznego przez tunel dla obu podsieci VLAN.
• ✓Zapewnienie braku komunikacji między VLAN 10 a VLAN 20 bez routingu przez router.
• ✓Weryfikacja łączności (ping) między stacjami w tych samych VLANach po obu stronach.
• ✓Weryfikacja braku komunikacji między VLAN 10 a VLAN 20 (izolacja warstwy 3).
• ✓Analiza tablicy routingu — obecność oddzielnych tras dla każdego VLAN.
• ✓Analiza tablicy ARP na hostach po obu stronach.
• ✓Udokumentowanie izolacji ruchu między VLANami.

• ✓L2 VPN (np. VPLS, Ether over VPN) — rozszerza warstwę 2 (Ethernet) przez tunel, komputery w różnych lokalizacjach są w tej samej sieci LAN (ten sam broadcast domain).
• ✓L3 VPN (np. GRE, IPSec) — każda lokalizacja ma własną podsieć IP, komunikacja odbywa się przez routing, izolacja broadcastów.
• ✓Rozciąganie L2 przez Internet jest ryzykowne: pakiety broadcastowe (ARP, DHCP Discovery, NetBIOS) są replikowane przez tunel, zwiększając bandwidth i opóźnienia.
• ✓Broadcast Storm (burza rozgłoszeniowa) — gdy pakiety broadcastowe krążą w pętli między przełącznikami w rozszerzonej sieci L2, może doprowadzić do zalania sieci i niedostępności.
• ✓Spanning Tree Protocol (STP) chroni przed fizycznymi pętlami, ale nie przed broadcast storm spowodowanym przez złośliwy ruch lub błędy konfiguracji.
• ✓L3 VPN jest bezpieczniejsze: izolacja broadcastów, mniejsze ryzyko burz, łatwiejsze zarządzanie i skalowanie.
• ✓Segmentacja VLAN przez VPN (jak w zadaniu) łączy zalety: logiczna separacja ruchu (VLAN) + bezpieczny tunel (GRE over IPSec) + kontrola routingu (L3).
• ✓Podsumowanie: L2 VPN stosować tylko gdy wymagana jest wspólna warstwa 2 (np. migracja serwerów), w pozostałych przypadkach L3 VPN jest bezpieczniejszy i wydajniejszy.