Jak działa Tailscale? Architektura sieci i zasady VPN

Czym jest Tailscale?

Tailscale to sieć VPN, która łączy maszyny bezpośrednio ze sobą, zamiast kierować cały ruch przez jedną bramę zarządzaną przez użytkownika. Każdy węzeł uruchamia WireGuard, dzięki czemu pakiety przesyłane są w formie zaszyfrowanej między serwerami, a elementy pośredniczące nie mają możliwości ich odczytania. Hostowany serwer koordynacyjny odpowiada za nawiązywanie połączeń. Przechowuje on i dystrybuuje klucze publiczne oraz informuje każdy węzeł o lokalizacji pozostałych. Przesyła również zdefiniowane reguły dostępu.

Ten podział stanowi fundament projektu. Płaszczyzna danych działa w modelu peer-to-peer i jest szyfrowana między węzłami. Płaszczyzna sterowania to usługa utrzymywana przez Tailscale. Każde istotne pytanie dotyczące Tailscale, w tym te dotyczące zaufania, wynika z tych dwóch faktów. Jeśli użytkownik zbudował już ręcznie sieć VPN opartą na WireGuard na serwerze VPS, Tailscale oferuje ten sam tunel, automatyzując dystrybucję kluczy oraz przechodzenie przez firewalle.

Jak działa Tailscale?

Prywatna sieć węzłów nazywana jest tailnet. W momencie dołączenia maszyny do sieci zachodzą cztery procesy.

1. Uruchamia się demon tailscaled, generuje parę kluczy WireGuard i przechowuje swój stan w /var/lib/tailscale/tailscaled.state. Klucz prywatny pozostaje na danej maszynie. Dokumentacja Tailscale określa to wprost: „klucz prywatny nigdy, pod żadnym pozorem nie opuszcza swojego węzła”.
2. Węzeł loguje się do serwera koordynacji i przesyła swój klucz publiczny oraz adresy, pod którymi jest dostępny. Tailscale opisuje ten serwer jako „wspólną skrzynkę odbiorczą dla kluczy publicznych”.
3. Serwer koordynacji odsyła mapę sieci: klucz publiczny, adres w tailnet, nazwę maszyny oraz potencjalne punkty końcowe każdego węzła, z którym dany węzeł może się komunikować.
4. Każda para węzłów próbuje następnie nawiązać bezpośredni tunel WireGuard między sobą. W przypadku niepowodzenia pakiety są przesyłane przez przekaźnik.

Każdy węzeł otrzymuje stabilny adres z puli 100.64.0.0/10, czyli zakresu carrier-grade NAT od 100.64.0.0 do 100.127.255.255. Tailscale korzysta z tego zakresu, ponieważ jest on zarezerwowany dla infrastruktury dostawców, dzięki czemu rzadko dochodzi do konfliktów z adresami prywatnymi już używanymi przez serwery. W systemie Linux tunel widoczny jest jako interfejs o nazwie tailscale0.

Implementacja WireGuard działa wewnątrz tailscaled w przestrzeni użytkownika (userspace), a nie jako moduł jądra. Dlatego Tailscale uruchamia się w wirtualizacji kontenerowej, gdzie sudo modprobe wireguard kończy się błędem Operation not supported. Oznacza to również, że maksymalna przepustowość na danej maszynie jest niższa niż w przypadku WireGuard działającego w jądrze, co jest jednym z kompromisów opisanych w Tailscale w porównaniu do standardowego WireGuard.

Dwa polecenia pozwalają sprawdzić bieżący stan.

tailscale ip -4
tailscale status

tailscale status wyświetla jeden wiersz na węzeł, przy czym kluczowa jest ostatnia kolumna.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct z podanym adresem i portem oznacza, że maszyny znalazły ścieżkę do siebie i ruch odbywa się w modelu peer-to-peer. relay "fra" oznacza, że ruch przechodzi przez przekaźnik Tailscale we Frankfurcie. - oznacza brak aktywnej sesji z danym węzłem, co jest stanem normalnym.

Co widzi, a czego nie widzi serwer koordynacji

Serwer koordynacji przechowuje klucze publiczne oraz metadane. Zna nazwy maszyn, informacje o tym, który użytkownik lub tag jest właścicielem danego węzła, adresy tailnet każdego węzła, publiczne adresy, pod którymi węzły są osiągalne, czas ostatniej aktywności oraz zdefiniowany plik polityki. Stanowi to pełną mapę infrastruktury.

Serwer nie posiada kluczy prywatnych, więc nie może odszyfrować ruchu między dwoma węzłami. Szyfrowanie odbywa się w modelu end-to-end między peerami WireGuard, a serwer koordynacji nie jest jednym z nich.

Serwer może natomiast przekazywać klucze. Każdemu serwerowi koordynacji, zarówno hostowanemu zewnętrznie, jak i uruchamianemu samodzielnie, powierza się zadanie informowania węzłów, które klucze publiczne należą do sieci tailnet. Jest to kluczowy element modelu zagrożeń opisanego poniżej oraz powód, dla którego istnieje Headscale, serwer koordynacji typu open-source do samodzielnego hostowania.

Jak dwa serwery za różnymi zaporami komunikują się bezpośrednio

NAT (network address translation) pozwala wielu maszynom współdzielić jeden publiczny adres IP. Twój VPS zazwyczaj posiada własny publiczny adres, jednak inne maszyny, które chcesz włączyć do sieci tailnet, często go nie mają: serwer domowy, serwer budujący w sieci biurowej czy urządzenie za zaporą dostawcy, której nie możesz edytować.

Tailscale znajduje ścieżkę, wykorzystując techniki oparte na standardach STUN (session traversal utilities for NAT) oraz ICE. Każdy węzeł wysyła mały pakiet UDP do serwera STUN i otrzymuje informację o publicznym adresie oraz porcie, które router przypisał do tego gniazda. Oba węzły zgłaszają te kandydatury do serwera koordynującego, który przekazuje je drugiej stronie. Następnie oba węzły zaczynają jednocześnie wysyłać pakiety do siebie nawzajem. Każdy router najpierw widzi pakiet wychodzący, więc tworzy mapowanie i akceptuje odpowiedź przychodzącą z tego samego adresu. Żadna ze stron nie wymagała reguły zapory dla ruchu przychodzącego.

Porty są ściśle określone. Bezpośrednie tunele WireGuard używają protokołu UDP z portem źródłowym, który domyślnie wynosi 41641. STUN działa przez UDP 3478 do serwerów przekaźnikowych Tailscale. Połączenie kontrolne oraz wszelkie przekazywane dane wykorzystują HTTPS na porcie TCP 443. W większości przypadków nie trzeba otwierać żadnego ruchu przychodzącego, choć w sieciach z restrykcyjnym NAT, zezwolenie na ruch przychodzący UDP 41641 zwiększa szansę na nawiązanie bezpośredniego połączenia.

tailscale netcheck

Odczytaj dwie linie tego raportu. UDP: true oznacza, że ruch UDP w ogóle opuszcza maszynę, a UDP: false oznacza, że każde połączenie z tego węzła będzie przekaźnikowane. MappingVariesByDestIP: true oznacza, że router przypisuje inny publiczny port dla każdego miejsca docelowego, więc powyższa metoda przewidywania adresu nie zadziała i takie węzły zazwyczaj pozostają w trybie przekaźnikowania.

Kiedy Tailscale korzysta z przekaźnika DERP

DERP (designated encrypted relay for packets) stanowi mechanizm awaryjny. Tailscale utrzymuje przekaźniki w wielu regionach, dostępne przez port TCP 443. Węzeł, który nie może nawiązać bezpośredniego połączenia, przesyła swoje pakiety WireGuard przez jeden z nich.

Pakiety pozostają zaszyfrowane. Tailscale deklaruje to jednoznacznie: „serwer DERP nigdy nie ma możliwości odszyfrowania ruchu. Przekazuje on jedynie w sposób ślepy zaszyfrowany ruch z jednego węzła do drugiego”. Przekaźnik widzi jedynie tekst zaszyfrowany oraz informację, które węzły się komunikują.

Przekaźniki obsługują również pierwsze pakiety większości połączeń. Ustalenie bezpośredniej ścieżki wymaga czasu, dlatego sesja często rozpoczyna się w trybie przekaźnikowym, a następnie przechodzi na połączenie bezpośrednie, gdy węzły się odnajdą. Można to zaobserwować.

tailscale ping db-1

Pierwsze odpowiedzi wracają jako via DERP(fra), a kolejna linia raportuje komunikat typu via 198.51.100.24:41641. Ta zmiana oznacza przejście na bezpośredni tunel. Jeśli stan ten nie ulega zmianie, należy uruchomić tailscale netcheck na obu końcach połączenia. Ścieżka przekaźnikowa nadal działa. Wiąże się to jednak z wyższymi opóźnieniami, ponieważ każdy pakiet musi przejść przez trzecią maszynę. Jeśli problemem są wolne transfery, a nie zerwane połączenie, dlaczego połączenie przekaźnikowe Tailscale jest znacznie wolniejsze niż bezpośrednie wyjaśnia różnice w wydajności oraz wskazuje, jak skonfigurować VPS, aby uzyskać bezpośrednią ścieżkę.

Dołączanie serwera VPS do sieci tailnet

Skrypt instalacyjny obsługuje systemy Ubuntu oraz Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up wyświetla adres URL. Należy go otworzyć, uwierzytelnić się, a węzeł pojawi się w konsoli administracyjnej. Następnie należy potwierdzić, że demon uruchamia się ponownie po restarcie systemu, ponieważ jest to krok często pomijany.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled powinno zwrócić enabled, a tailscale status powinno wyświetlić nowy węzeł wraz z jego adresem 100.x. W przypadku serwera konfigurowanego za pomocą skryptu, interaktywny adres URL jest bezużyteczny. Należy wygenerować klucz uwierzytelniający (auth key) w konsoli administracyjnej i przekazać go wraz z tagiem określającym typ maszyny.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Węzeł z przypisanym tagiem jest własnością tego tagu, a nie użytkownika, który wykonał polecenie, dzięki czemu działa on nadal po usunięciu konta tego użytkownika. Tag musi zostać najpierw zadeklarowany w pliku polityki w sekcji tagOwners, w przeciwnym razie polecenie zostanie odrzucone. Tagowanie zmienia również sposób rozliczania maszyny w ramach planu, ponieważ zasoby otagowane są wyceniane oddzielnie od urządzeń osobistych, a zakres darmowego planu określa limity dla tych zasobów.

Dla zarządzania flotą istotne są dwa ustawienia. Klucze węzłów wygasają domyślnie po 180 dniach (stan na sierpień 2026), a po wygaśnięciu klucza „połączenia do/z danego punktu końcowego przestaną działać” do momentu ponownego zalogowania. Dlatego dla serwerów bezobsługowych należy otworzyć wiersz maszyny w konsoli administracyjnej i wybrać opcję Disable Key Expiry. Funkcja MagicDNS, włączona domyślnie dla sieci tailnet utworzonych 20 października 2022 roku lub później, nadaje każdemu węzłowi nazwę typu db-1.yak-bebop.ts.net, rozwiązywaną przez lokalny resolver pod adresem 100.100.100.100. Należy używać nazw zamiast adresów IP, ponieważ przebudowany węzeł otrzymuje nowy adres, zachowując swoją nazwę.

Jeśli sama instalacja kończy się niepowodzeniem na etapie apt lub repozytorium, typowe błędy instalacji Tailscale w systemie Ubuntu zawierają opis rozwiązań.

Uzyskiwanie dostępu do usługi powiązanej z localhost

W tym miejscu przydatna staje się sieć tailnet i tutaj użytkownicy często napotykają trudności. Dołączenie do sieci tailnet nie sprawia automatycznie, że usługa działająca na interfejsie loopback staje się dostępna.

ss -tlnp | grep 3000

Jeśli polecenie to zwraca 127.0.0.1:3000, gniazdo akceptuje wyłącznie pakiety, których adresem docelowym jest 127.0.0.1. Żądanie z innego węzła dociera zaadresowane do adresu 100.x tego węzła, więc jądro systemu nie posiada nasłuchującego procesu dla tego adresu i odpowiada komunikatem TCP reset. Klient zgłasza błąd Connection refused. Tunel działa poprawnie. Problemem jest konfiguracja nasłuchiwania.

Istnieją dwa poprawne rozwiązania. Powiąż usługę z adresem tailnet węzła, co pozwoli zachować ją poza publicznym interfejsem bez pośrednictwa proxy: przekaż --bind 100.101.102.104 lub odpowiednią opcję w konfiguracji, a w przypadku kontenera opublikuj port jako -p 100.101.102.104:3000:3000. Alternatywnie, pozostaw usługę na interfejsie loopback i umieść przed nią Tailscale.

tailscale serve 3000

To rozwiązanie przekazuje żądania do http://127.0.0.1:3000 i udostępnia je wewnątrz sieci tailnet pod nazwą ts.net przez HTTPS, po uprzednim włączeniu certyfikatów HTTPS dla sieci tailnet. Usługa pozostaje prywatna dla Twoich węzłów. Publiczną wersją tego samego mechanizmu jest Funnel, a artykuł Tailscale serve a funnel wyjaśnia, który z nich wybrać.

Dwa powiązane zadania posiadają własne strony dokumentacji. Uzyskanie dostępu do całej sieci prywatnej, w której nie zainstalowano Tailscale, wymaga routera podsieci na VPS, a kierowanie wychodzącego ruchu internetowego węzła przez inny węzeł wymaga węzła wyjściowego (exit node).

Zamykanie niepotrzebnych portów

Gdy administrator uzyskuje dostęp do serwera przez tailnet, publiczny port 22 staje się zbędny. To praktyczna korzyść: zamkniętego portu nie można atakować metodą brute force, a dzienniki przestają zapełniać się próbami logowania.

Kolejność działań ma znaczenie. Najpierw należy skonfigurować dostęp przez tailnet, potwierdzić możliwość zalogowania się z drugiej sesji, a dopiero potem usunąć regułę publiczną.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Następnie należy usunąć publiczną regułę SSH i połączyć się ponownie, używając nazwy MagicDNS. Należy pamiętać, jak działa ufw allow in on tailscale0: ufa ono wszystkiemu, co dociera przez tunel, więc to plik polityki Tailscale staje się kontrolą dostępu zamiast ufw. Politykę należy przygotować z uwzględnieniem tego faktu.

Ostrzeżenie dla użytkowników kontenerów. Opublikowany port Docker instaluje własne reguły NAT i omija ufw, więc ufw deny go nie zamknie. Publikowanie portów Docker z pominięciem ufw wyjaśnia ten mechanizm. Publikowanie na adresie tailnet, zgodnie z powyższym opisem, pozwala tego uniknąć. Jeśli aplikacja działa w Docker Compose, sidecar Tailscale w stosie Compose pozwala pójść o krok dalej i całkowicie usunąć opublikowany port, pozostawiając kontener dostępny wyłącznie pod jego nazwą w tailnet.

Co chroni Tailscale, a czego nie chroni

Warto to jasno określić, ponieważ wersja marketingowa zaciera te granice.

Chronione: ruch między dwoma węzłami jest szyfrowany metodą end-to-end za pomocą WireGuard i żaden przekaźnik pośredniczący nie może go odczytać. Klucze prywatne nigdy nie opuszczają maszyny, na której zostały wygenerowane. Węzły nie wymagają otwartych portów przychodzących, więc w Internecie nie ma nic na portach 22 lub 5432, co można by przeskanować. Dostęp między węzłami jest określany przez plik polityki, a nie przez to, kto zna adres.

Niechronione: serwer koordynujący widzi graf urządzeń. Te metadane same w sobie są wrażliwe, ponieważ nazwy maszyn, właściciele, adresy i czasy aktywności opisują infrastrukturę. Serwer dystrybuuje również klucze, co stanowi poważniejsze ryzyko. Tailscale stwierdza to wprost: „Gdyby Tailscale działało w złej wierze i potajemnie wprowadziło nowe węzły do sieci, mogłoby wysyłać lub odbierać ruch do istniejących węzłów w postaci jawnej”. Dostawca SSO znajduje się na tej samej ścieżce zaufania, ponieważ każdy, kto może wygenerować tam tożsamość, może dodać węzeł. Ponadto przejęty węzeł jest równorzędnym elementem wewnątrz tailnet, więc jego zasięg ogranicza jedynie polityka bezpieczeństwa. To, czy stanowi to akceptowalne ryzyko, zależy od tego, przed kim się bronisz, a pełny model zaufania omawia każdy z tych przypadków, w tym możliwości skradzionego konta tożsamości.

Istnieją dwie odpowiedzi na ryzyko związane z dystrybucją kluczy. Pierwszą jest tailnet lock, który wymaga, aby istniejące zaufane węzły kryptograficznie podpisały nowy węzeł, zanim inne węzły go zaakceptują. Płaszczyzna sterowania, która dodaje węzeł bez ważnego podpisu, jest ignorowana. Konsola administracyjna generuje dokładną linię tailscale lock init dla węzłów podpisujących, a każdy węzeł może potwierdzić to, co widzi.

tailscale lock status

Wszystkie węzły powinny zgłaszać ten sam zestaw zaufanych kluczy podpisujących. Drugą odpowiedzią jest samodzielne uruchomienie płaszczyzny sterowania. Samodzielnie hostowany serwer koordynujący Headscale obsługuje ten sam protokół dla tych samych klientów, co przenosi graf urządzeń i dystrybucję kluczy na sprzęt będący własnością użytkownika. Wówczas użytkownik odpowiada również za czas dostępności tego serwera. Jeśli nadal porównujesz samodzielnie hostowane płaszczyzny sterowania, zamiast zdecydować się na tę, NetBird jest oddzielnym rozwiązaniem mesh VPN, którego serwer uruchamia się w całości na pojedynczym VPS.

Jedno ustawienie domyślne do zmiany pierwszego dnia. Nowy tailnet jest domyślnie permisywny: „domyślny plik polityki tailnet umożliwia komunikację między wszystkimi urządzeniami wewnątrz tailnet”. Gdy tylko dodasz sekcję acls, model zmienia się na domyślną odmowę (deny by default) i przepuszczane są tylko zdefiniowane reguły.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Ta polityka pozwala członkom tailnet na dostęp do SSH na otagowanych serwerach i niczego więcej. Dodawaj regułę dla każdej usługi zamiast pozostawiać symbol wieloznaczny, ponieważ symbol wieloznaczny oznacza, że jeden skradziony klucz z laptopa daje dostęp do bazy danych.

Tryby awarii i komunikaty błędów

tailscale status zawsze zwraca relay. Węzły nie nawiązały bezpośredniego połączenia. Uruchom tailscale netcheck na obu końcach. UDP: false oznacza, że ruch UDP jest blokowany w kierunku wychodzącym, więc jedyną opcją jest użycie przekaźnika (relay). MappingVariesByDestIP: true oznacza obecność restrykcyjnego NAT-u; problem często rozwiązuje otwarcie portu UDP 41641 dla ruchu przychodzącego na kontrolowanym węźle.

Węzeł, który działał przez miesiące, przestał być widoczny. Klucz węzła wygasł zgodnie z domyślnym okresem 180 dni. W konsoli administracyjnej maszyna widnieje jako wygasła, a wykonanie sudo tailscale up na danym urządzeniu przywraca jego dostępność. Wyłącz wygasanie kluczy na serwerach, aby uniknąć powtórzenia tego problemu.

Węzły są widoczne na liście, ale połączenia kończą się przekroczeniem czasu oczekiwania. Łączność sieciowa działa, ale polityka bezpieczeństwa blokuje ruch. Sprawdź sekcję acls pod kątem reguły obejmującej dane źródło, cel oraz port. Odrzucony pakiet jest porzucany bez odpowiedzi, co skutkuje przekroczeniem czasu oczekiwania zamiast błędu Connection refused.

Nazwy MagicDNS nie są rozwiązywane. ping db-1 kończy się niepowodzeniem, podczas gdy ping 100.101.102.104 działa poprawnie. Inny proces nadpisał /etc/resolv.conf, przez co zapytania nie docierają do lokalnego resolvera 100.100.100.100. Sprawdź cat /etc/resolv.conf pod kątem 100.100.100.100 oraz zweryfikuj, jakie inne procesy na maszynie modyfikują ten plik. Jest to ten sam typ problemu, co awaria DNS wewnątrz tunelu WireGuard.

tailscale up odrzuca tag. Tag nie został zadeklarowany w sekcji tagOwners w pliku polityki. Dodaj go w tym miejscu i uruchom polecenie ponownie.

FAQ

Czy Tailscale to VPN czy sieć typu mesh?

Oba określenia są poprawne, ponieważ opisują różne warstwy działania. Tunele oparte są na protokole WireGuard, co czyni rozwiązanie siecią VPN. Topologia to mesh, ponieważ każdy węzeł buduje tunel bezpośrednio do węzła, z którym się komunikuje, zamiast przesyłać każdy pakiet przez centralny serwer. Serwer koordynujący znajduje się w ścieżce sterowania, a nie w ścieżce danych, więc w przypadku utraty łączności z nim, istniejące tunele nadal przesyłają ruch. Podczas awarii serwera koordynującego niemożliwe jest jedynie dołączanie nowych węzłów oraz wprowadzanie zmian w kluczach lub politykach.

Czy Tailscale może odczytać mój ruch?

Nie, nie może odczytać zawartości. Ruch jest szyfrowany end-to-end między węzłami za pomocą WireGuard, klucze prywatne nigdy nie opuszczają węzłów, a przekaźnik DERP przekazuje pakiety, których nie jest w stanie odszyfrować. Tailscale widzi metadane: nazwy maszyn, właścicieli, klucze publiczne, adresy punktów końcowych oraz status dostępności węzłów. Serwer dystrybuuje również klucze, więc w przypadku jego przejęcia, atakujący mógłby próbować dodać węzeł, któremu flota mogłaby zaufać. Mechanizm tailnet lock zapobiega temu, wymagając podpisów z własnych zaufanych węzłów, a Headscale pozwala całkowicie wyeliminować zewnętrzny serwer kontrolny.

Czy muszę otwierać porty w zaporze dla Tailscale?

Prawie nigdy dla ruchu przychodzącego. Zgodnie z wytycznymi Tailscale, „przez większość czasu nie trzeba otwierać żadnych portów w zaporze”. W ruchu wychodzącym węzeł wymaga dostępu do portu TCP 443 na serwerze koordynującym i przekaźnikach, oraz UDP 3478 dla STUN. Tunele bezpośrednie używają protokołu UDP z portem źródłowym, który domyślnie ma wartość 41641. Zezwolenie na ruch przychodzący UDP 41641 jest opcjonalne i pomaga jedynie w nawiązywaniu połączeń bezpośrednich w trudnych warunkach sieciowych.

Dlaczego inne węzły nie mogą połączyć się z moją usługą na porcie 3000?

W pierwszej kolejności sprawdź adres powiązania (bind address) za pomocą ss -tlnp. Proces nasłuchujący na 127.0.0.1:3000 odrzuca połączenia przychodzące na adres 100.x z sieci tailnet, ponieważ gniazdo akceptuje tylko połączenia lokalne (loopback), a klient otrzymuje błąd Connection refused. Powiąż usługę z adresem sieci tailnet lub uruchom tailscale serve 3000, aby przekierować ruch. Jeśli proces nasłuchuje już na 0.0.0.0, a połączenie kończy się przekroczeniem czasu oczekiwania zamiast odrzuceniem, przyczyną jest reguła polityki lub lokalna zapora sieciowa, a nie adres powiązania.

Czy powinienem używać Headscale zamiast serwera koordynującego Tailscale?

Używaj Headscale, gdy graf urządzeń lub dystrybucja kluczy muszą znajdować się na infrastrukturze, którą kontrolujesz, lub gdy sieć tailnet musi działać bez zależności od zewnętrznej usługi. Klienci i protokół pozostają takie same. Kosztem jest konieczność samodzielnego utrzymywania serwera koordynującego, którego awaria uniemożliwia dołączanie nowych węzłów i stosowanie zmian w politykach. W przypadku małej floty, korzystanie z hostowanej płaszczyzny kontrolnej z włączonym mechanizmem tailnet lock jest zazwyczaj korzystniejszym rozwiązaniem.