Jak uruchomić Gemini CLI na VPS headless

Cel projektu

Celem jest uruchomienie usługi Gemini CLI w trybie ciągłym na własnym serwerze, dostępnej przez SSH. Narzędzie umożliwia wykonywanie długotrwałych zadań agentowych, które kontynuują pracę po zamknięciu sesji lokalnej. Instalacja wymaga wykonania trzech komend. Głównym wyzwaniem jest brak środowiska graficznego: interfejs CLI Google wymaga przeglądarki do logowania, której serwer nie posiada. Dlatego niniejszy poradnik skupia się na metodzie headless: instalacji aktualnej wersji Node.js (niedostępnej w standardowych repozytoriach dystrybucji), globalnej instalacji npm bez uprawnień root, autoryzacji bez przeglądarki przy użyciu klucza API (niewidocznego w historii powłoki) oraz wykorzystaniu tmux, aby przerwanie sesji SSH nie przerwało trwającego zadania.

Gemini CLI to program Node (@google/gemini-cli) o otwartym kodzie źródłowym (Apache-2.0), który komunikuje się z modelami Google Gemini. Narzędzie posiada uprawnienia do odczytu i zapisu plików, wykonywania komend shell oraz obsługi narzędzi w katalogu roboczym. Na maszynie VPS działa jako stały agent, który można pozostawić do pracy. Z tego powodu kluczowe znaczenie mają konto użytkownika, na którym działa proces, oraz dane uwierzytelniające zapisane na dysku.

Wymagania wstępne i znane problemy

• Czysty system Ubuntu 24.04 KVM VPS z uprawnieniami root lub sudo. Każdy plan KVM jest odpowiedni; samo CLI jest lekkie i w stanie spoczynku zajmuje kilka setek MB RAM.
• Node.js w wersji 20 lub nowszej. Jest to jedyny sztywny wymóg wersji; pakiety dystrybucyjne są starsze — patrz sekcja obok.
• Dostęp wychodzący HTTPS (port 443) do Google APIs. Nie są wymagane żadne porty przychodzące; rozwiązanie działa jako klient, a nie serwer, więc nie należy otwierać żadnych dziur w firewallu.
• Metoda uwierzytelniania niewymagająca przeglądarki na serwerze: klucz Gemini API z Google AI Studio lub tunel SSH do przeglądarki na lokalnej maszynie. Metoda z kluczem API jest zalecana do skryptów i procesów działających bez nadzoru.
• Docker lub Podman, wyłącznie jeśli wymagana jest izolacja --sandbox. Opcjonalne, opisane na końcu.

Problem, na który natyka każdy użytkownik: proces logowania gemini przy pierwszym uruchomieniu jest przeznaczony dla systemów desktopowych. Próbuje on otworzyć przeglądarkę, co na systemach typu headless kończy się błędem lub wyświetleniem niedziałającego linku. Należy wybrać metodę uwierzytelniania przed rozpoczęciem pracy.

Node: pakiet dystrybucji jest zbyt stary

Ubuntu 24.04 dostarcza Node 18.19.1 w swoich repozytoriach wraz z npm 9.2.0. Gemini CLI deklaruje engines: { node: ">=20" } w package.json, a npm domyślnie nie blokuje niezgodności wersji — instalacja przebiega pomyślnie, lecz wyświetlany jest komunikat o rozbieżności:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@google/gemini-cli@0.50.0',
npm WARN EBADENGINE   required: { node: '>=20' },
npm WARN EBADENGINE   current: { node: 'v18.19.1', npm: '9.2.0' }
npm WARN EBADENGINE }

Zignorowanie tego ostrzeżenia powoduje uruchomienie CLI na nieobsługiwanej wersji runtime. Narzędzie może działać nieprawidłowo lub ulec awarii po wywołaniu API dostępnego w Node 20+. Wersja Node 18 osiągnęła koniec wsparcia (end-of-life) w kwietniu 2025, więc jest ona nieprzydatna. Należy zainstalować aktualną wersję LTS przed instalacją CLI. Dostępne są dwie metody: NodeSource (podpisane repozytorium apt dla całego systemu) lub nvm (menedżer wersji dla konkretnego użytkownika). Należy wybrać jedną z nich.

NodeSource, jeśli Node ma być dostępny dla każdego użytkownika w systemie:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version

node --version musi zwracać v20.x lub nowszą wersję — v24.x to obecnie aktywna wersja LTS. Należy sprawdzić stronę NodeSource w celu uzyskania aktualnego skryptu instalacyjnego; należy zmienić wartość setup_24.x w adresie URL po wydaniu nowszej wersji LTS.

nvm, jeśli Node ma znajdować się w katalogu home danego użytkownika i nie wymaga użycia sudo:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
node --version

Wersja v0.40.1 w podanym adresie URL była aktualna w momencie publikacji dokumentu; należy sprawdzić plik README projektu nvm w celu uzyskania najnowszej wersji i podmienić numer wersji przed uruchomieniem. nvm ma istotną zaletę w tym przypadku: instaluje Node oraz pakiety globalne w ~/.nvm, co eliminuje problem uprawnień przy instalacji globalnej opisany w następnej sekcji. W przypadku użycia nvm można pominąć krok konfiguracji npm-prefix.

Instalacja CLI bez sudo npm -g

Poleceniem, które może wydawać się kuszące, jest sudo npm install -g @google/gemini-cli. Nie należy go używać. Globalny prefix należący do użytkownika root powoduje błędy uprawnień podczas każdej późniejszej instalacji. Powoduje to również pozostawienie plików należących do root w pamięci podręcznej npm, co spowoduje problemy w przyszłości. Uruchomienie zwykłego (bez sudo) npm install -g względem systemowego Node skutkuje innym błędem:

npm error code EACCES
npm error syscall mkdir
npm error path /usr/lib/node_modules/@google
npm error errno -13
npm error Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@google'

Występuje tam próba zapisu npm do /usr/lib, do czego użytkownik nie ma uprawnień. Rozwiązaniem nie jest użycie sudo. Należy ustawić globalny prefix npm na katalog domowy, aby instalacje globalne trafiały w miejsce, do którego użytkownik ma uprawnienia:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @google/gemini-cli
gemini --version

Użycie ~/.bashrc zamiast ~/.profile jest celowe: tmux — który zostanie uruchomiony wewnątrz CLI za dwa kroki — uruchamia shell typu non-login, który odczytuje ~/.bashrc i pomija ~/.profile. W związku z tym linia PATH w niewłaściwym pliku spowoduje, że gemini będzie niewidoczny dokładnie tam, gdzie jest wymagany. Wyświetlenie numeru wersji przez gemini --version stanowi pełny test. Jeśli zamiast tego wystąpi błąd gemini: command not found, oznacza to, że eksport PATH nie został zastosowany — należy sprawdzić możliwe przyczyny błędów. W przypadku nvm należy całkowicie pominąć linie dotyczące prefixu: nvm automatycznie instaluje pakiety globalne w katalogu domowym.

Jeśli wcześniej uruchomiono sudo npm, a obecnie widoczny jest błąd Your cache folder contains root-owned files, należy naprawić to za pomocą sudo chown -R $(id -u):$(id -g) ~/.npm.

Problem z uwierzytelnianiem headless i sposób na jego rozwiązanie

Podczas pierwszej interaktywnej sesji gemini program zaproponuje logowanie za pomocą konta Google. Na komputerze stacjonarnym otworzy to nową kartę przeglądarki. Na serwerze VPS typu headless brak jest przeglądarki, więc proces albo wyświetli adres URL localhost do ręcznego otwarcia, albo zakończy się błędem:

Failed to open browser. Please visit the following URL to authorize:
https://accounts.google.com/o/oauth2/v2/auth?...&redirect_uri=http://localhost:PORT

Przyczyną problemu jest redirect_uri=http://localhost:PORT. Nawet po otwarciu tego adresu URL na laptopie i zatwierdzeniu operacji, Google przekierowuje na http://localhost:PORT — czyli localhost na serwerze, do portu niedostępnego z poziomu laptopa. Logowanie nie zostanie ukończone.

Istnieją dwa poprawne sposoby rozwiązania tego problemu.

Pierwszym sposobem jest użycie klucza API, co jest zalecanym rozwiązaniem dla serwerów. Należy utworzyć klucz w Google AI Studio (aistudio.google.com) i przekazać go do CLI jako zmienną środowiskową; program odczyta GEMINI_API_KEY i całkowicie pominie proces przeglądarkowy. Należy jednak pamiętać o bezpieczeństwie. Nie należy wpisywać export GEMINI_API_KEY=AIza... bezpośrednio w konsoli — dane zostaną zapisane w ~/.bash_history w postaci jawnej. Nie należy również umieszczać klucza w plikach dostępnych dla innych użytkowników. Należy zapisać go w pliku z uprawnieniami mode-600, który powłoka (shell) załaduje przy starcie:

umask 077
printf 'export GEMINI_API_KEY=%s\n' 'AIzaSyYOUR_KEY_HERE' > ~/.gemini_env
chmod 600 ~/.gemini_env
echo '[ -f ~/.gemini_env ] && . ~/.gemini_env' >> ~/.bashrc
source ~/.bashrc

chmod 600 oznacza, że plik może odczytać wyłącznie bieżący użytkownik. Aby potwierdzić, czy klucz został poprawnie wczytany do środowiska, należy użyć printenv GEMINI_API_KEY; jeśli polecenie nie wyświetli nic, CLI spróbuje użyć przeglądarki i zakończy proces błędem. Program odczytuje również plik .env w ~/.gemini/, jeśli taki format jest preferowany — obowiązuje ta sama zasada, czyli chmod 600 ~/.gemini/.env.

Drugi sposób pozwala na korzystanie z logowania kontem osobistym Google (wraz z darmowym limitem) poprzez przekierowanie (tunnelling) powiadomienia OAuth z powrotem na laptopa. Problem polega na tym, że serwer loopback CLI przy każdym uruchomieniu zajmuje losowy port. Aby umożliwić przekierowanie, należy najpierw przypisać stały port za pomocą zmiennej środowiskowej OAUTH_CALLBACK_PORT, a następnie przekierować dokładnie ten port:

# from your laptop, forward the callback port into the SSH session:
ssh -L 8085:localhost:8085 user@your-server
# then, on the server, pin the callback to the same port and start the CLI:
export OAUTH_CALLBACK_PORT=8085
gemini

Ponieważ CLI nie może otworzyć przeglądarki, wyświetli adres URL do uwierzytelniania. Należy otworzyć go w przeglądarce na laptopie i zatwierdzić operację. Gdy Google przekieruje na http://localhost:8085/..., tunel SSH przekaże żądanie do serwera loopback na VPS, co zakończy proces logowania. Jeśli port nie zostanie przypisany na stałe, przy każdym uruchomieniu zostanie użyty nowy losowy port, którego nie da się przechwycić za pomocą wcześniej skonfigurowanego ssh -L. Metoda ta działa, ale wymaga aktywnej sesji przeglądarki, więc nie nadaje się do skryptów. W przypadku procesów działających w tle należy używać klucza API.

W przypadku korzystania z Vertex AI lub projektu Google Cloud zamiast AI Studio, należy ustawić GOOGLE_API_KEY wraz z GOOGLE_GENAI_USE_VERTEXAI=true lub GOOGLE_CLOUD_PROJECT dla licencji Code Assist — obowiązują te same zasady dotyczące zmiennych środowiskowych oraz plików mode-600.

Uruchom proces wewnątrz tmux, aby przerwana sesja SSH nie zakończyła jego działania

Proces gemini uruchomiony bezpośrednio z powłoki SSH jest procesem potomnym tej powłoki. Utrata połączenia — zamknięcie laptopa, przerwanie połączenia Wi-Fi lub wygaśnięcie czasu bezczynności — powoduje, że sshd zamyka pseudo-terminal. Powłoka otrzymuje sygnał SIGHUP, co skutkuje zamknięciem interfejsu CLI. Zadanie, które trwało dziesięć minut podczas edycji plików, zostaje przerwane, a po ponownym połączeniu proces nie będzie dostępny do odzyskania.

tmux rozwiązuje ten problem poprzez przejęcie kontroli nad powłoką zamiast sshd. Jest to ten sam schemat, co w przypadku uruchamiania agenta AI do kodowania na zdalnym VPS wewnątrz tmux, i działa on tutaj identycznie:

sudo apt install -y tmux
tmux new -A -s gemini
# inside the session:
gemini
# detach with Ctrl-b then d — the task keeps running
# reconnect later from any machine:
tmux attach -t gemini

tmux new -A -s gemini łączy się z sesją o nazwie gemini, jeśli ona istnieje, lub tworzy nową, jeśli nie istnieje. Jest to jedyna komenda, którą należy wykonać natychmiast po każdym zalogowaniu. Powłoka wewnątrz sesji należy do odłączonego serwera tmux, a nie do sesji SSH, dzięki czemu przerwanie połączenia nie przerywa pracy CLI. Po ponownym połączeniu i wykonaniu polecenia attach, użytkownik wraca do tego samego bufora przewijania.

W przypadku nieinteraktywnych uruchomień skryptowych Gemini CLI posiada tryb headless: gemini -p "summarise the failing tests in this repo" wypisuje odpowiedź i kończy działanie, natomiast --output-format json generuje dane w formacie czytelnym dla maszyn, które można przekazać do innego procesu. Tryb headless z kluczem API jest zalecany podczas pracy w sesji tmux wykonującej długotrwałe zadania wsadowe lub przy uruchamianiu przez cron — istnieje jednak jedno zastrzeżenie: zadania cron nie ładują plików konfiguracyjnych logowania. Należy zatem podać własny GEMINI_API_KEY w linii crontab (lub nakazać komendzie załadowanie ~/.gemini_env), w przeciwnym razie CLI przejdzie w tryb przeglądarkowy, co spowoduje błąd.

Sandboxing i uprawnienia na maszynie pracującej również w środowisku produkcyjnym

Agent z dostępem do powłoki (shell) posiada uprawnienia powłoki. Gemini CLI może wykonywać polecenia, a domyślnie prosi o zatwierdzenie każdego ryzykownego działania — jednak użytkownicy często wybierają --yolo (automatyczne zatwierdzanie każdego wywołania narzędzia). W takim przypadku agent może usuwać pliki, wysyłać zmiany do git lub komunikować się z wewnętrznymi usługami z pełnymi uprawnieniami użytkownika, na którym jest uruchomiony. Na maszynie obsługującej również produkcję stanowi to realne zagrożenie, a nie teoretyczny scenariusz.

Trzy mechanizmy kontrolne, uszeregowane według stopnia zapewnianego bezpieczeństwa:

• Uruchomienie jako dedykowany, nieuprzywilejowany użytkownik. Nie jako root, ani nie jako członek grupy sudo. Należy utworzyć użytkownika agent z własnym katalogiem home, zainstalować tam Node oraz CLI; błąd w instrukcji ograniczy działanie agenta wyłącznie do tego konta. Jest to najważniejsza decyzja pod kątem bezpieczeństwa.
• Przechowywanie poświadczeń produkcyjnych poza maszyną. Brak produkcyjnych ~/.aws/credentials, brak skopiowanych z produkcji .env oraz brak haseł do baz danych z uprawnieniami do zapisu w krytycznych zasobach. Należy nadać agentowi poświadczenia do środowiska staging lub uprawnienia tylko do odczytu.
• Wykorzystanie wbudowanego piaskownicy (sandbox). Przy zainstalowanych Docker lub Podman, gemini --sandbox (lub GEMINI_SANDBOX=docker) uruchamia wywołania narzędzi agenta wewnątrz kontenera odizolowanego od systemu plików i sieci hosta. Nie zastępuje to nieuprzywilejowanego użytkownika, ale stanowi silną drugą warstwę ochrony, gdy ten sam VPS obsługuje procesy produkcyjne.

Jeśli Gemini CLI jest uruchamiany obok innych narzędzi self-hosted — na przykład serwera MCP udostępniającego narzędzia agentowi na tym samym VPS — należy traktować każdą nową funkcjonalność jako zwiększenie powierzchni ataku dostępnej dla agenta. Tokeny przekazywane agentowi powinny być ograniczone ściśle do jednego zadania.

Kwota, koszty oraz wybrana metoda uwierzytelniania

Metoda uwierzytelniania określa sposób naliczania opłat. Prywatne konto Google (metoda OAuth) korzysta z bezpłatnego poziomu Gemini Code Assist z limitami na minutę oraz dzień. Przekroczenie limitów powoduje błędy typu rate-limit do czasu resetu okna czasowego. Klucz API z AI Studio może być bezpłatny lub płatny, zależnie od projektu — klucz płatny zwiększa limity i nalicza opłaty za każdy token. Uwierzytelnianie przez Vertex lub projekt Cloud odbywa się poprzez Google Cloud.

Dwie praktyczne uwagi. Agent działający w pętli bez nadzoru może szybko wyczerpać kwotę, dlatego należy monitorować proces podczas pierwszych uruchomień przed dodaniem go do cron. Jeśli powodem wyboru modelu po stronie serwera jest prywatność lub nielimitowana inferencja, zamiast modeli hostowanych przez Google, należy użyć innego narzędzia — self-hosting an open LLM with Ollama on a VPS pozwala zachować wagi i prompty na własnym serwerze, kosztem uruchomienia znacznie mniejszego modelu niż Gemini.

Keeping it updated

Wersje Gemini CLI są często aktualizowane. Ponieważ narzędzie zostało zainstalowane w prefiksie należącym do użytkownika, aktualizacje nie wymagają uprawnień sudo:

npm install -g @google/gemini-cli@latest
gemini --version

Dostępne są kanały wydawnicze: @latest to wersja stabilna, @preview to cotygodniowa wersja preview, @nightly to wersja bleeding edge — zaleca się wybór @latest w przypadku systemów krytycznych. W przypadku nvm pakiety globalne znajdują się w katalogu aktywnej wersji Node, zatem po wykonaniu nvm use w celu zmiany wersji Node może być wymagana ponowna instalacja CLI. Zaleca się śledzenie informacji w release notes zamiast instalowania każdej poprawki.

Tryby awarii, dokładne komunikaty

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, a następnie błąd krytyczny CLI podczas działania. Wersja Node jest zbyt stara — dystrybucja posiada wersję 18.19.1, która osiągnęła koniec wsparcia (end-of-life). Należy zainstalować Node 20+ z repozytorium NodeSource lub za pomocą nvm, zweryfikować za pomocą node --version, a w przypadku wielu zainstalowanych wersji Node, upewnić się, że which node wskazuje na nową wersję, a nie na /usr/bin/node.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Globalna instalacja w prefiksie należącym do użytkownika root. Nie należy używać sudo — należy ustawić npm config set prefix ~/.npm-global, umieścić ~/.npm-global/bin w PATH i ponownie zainstalować aplikację jako zwykły użytkownik. Jeśli poprzednia sudo npm pozostawiła pliki cache należące do root (Your cache folder contains root-owned files), należy uruchomić sudo chown -R $(id -u):$(id -g) ~/.npm.

Failed to open browser, zawieszenie logowania lub redirect_uri=http://localhost:PORT nieosiągalny. Proces OAuth wymaga przeglądarki, której nie ma na serwerze, a callback localhost wskazuje na serwer zamiast na laptopa. Należy użyć metody API-key (GEMINI_API_KEY) lub przypisać OAUTH_CALLBACK_PORT, przekierować połączenie przez SSH za pomocą ssh -L i otworzyć URL lokalnie.

Proces został przerwany po rozłączeniu sesji SSH. Komenda gemini została uruchomiona bezpośrednio w powłoce SSH, przez co była procesem zależnym od tej powłoki i została zamknięta wraz z pty po rozłączeniu. Nie ma możliwości odzyskania procesu. Każdą sesję należy rozpoczynać od tmux new -A -s gemini i uruchamiać CLI wewnątrz niej.

Autoryzacja nadal nie działa mimo ustawienia klucza — CLI powraca do wyboru metody autoryzacji lub żądanie zwraca API key not valid z błędem HTTP 400. Klucz nie znajduje się w środowisku widocznym dla CLI. Należy zweryfikować to za pomocą printenv GEMINI_API_KEY; jeśli zmienna jest pusta, plik ~/.gemini_env nie został załadowany — należy sprawdzić, czy linijka znajduje się w ~/.bashrc, który jest odczytywany przez powłoki interaktywne (w tym tmux), ale nie jest odczytywany przez cron oraz inne powłoki nieinteraktywne. Dodatkowa spacja lub cudzysłów wewnątrz wartości klucza również powoduje błąd API key not valid.

429 / RESOURCE_EXHAUSTED / komunikat o przekroczeniu limitu (rate-limit). Przekroczono limit zapytań dla poziomu autoryzacji. Należy odczekać do resetu okna czasowego, zmniejszyć częstotliwość zapytań agenta lub przejść na płatny klucz API. Agent znajdujący się w pętli ponowień (retry loop) stale wywołuje ten błąd — należy go zatrzymać i sprawdzić wykonywane działania.

FAQ

Jak uwierzytelnić Gemini CLI na serwerze headless?

Należy użyć klucza API zamiast logowania przez przeglądarkę. Należy wygenerować klucz w Google AI Studio, umieścić go w pliku mode-600, który jest ładowany przez powłokę (export GEMINI_API_KEY=...), a wtedy CLI całkowicie pomija proces OAuth w przeglądarce. W przypadku chęci korzystania z bezpłatnego poziomu darmowego dla kont osobistych, należy przypisać port loopback za pomocą OAUTH_CALLBACK_PORT=8085, przekierować go na laptopa za pomocą ssh -L 8085:localhost:8085 user@server i otworzyć wydrukowany adres URL lokalnie — wymaga to jednak obecności przy przeglądarce, więc rozwiązanie to nie nadaje się do skryptów.

Dlaczego instalacja globalna npm wymaga sudo i jak tego uniknąć?

Domyślny prefiks globalny npm to /usr/lib/node_modules, do którego użytkownik nie ma uprawnień zapisu, dlatego zwykłe polecenie npm install -g kończy się błędem EACCES. Nieprawidłowym rozwiązaniem jest sudo npm -g, co skutkuje powstaniem plików należących do root, co powoduje błędy przy późniejszych instalacjach. Poprawnym rozwiązaniem jest ustawienie prefiksu w katalogu domowym (npm config set prefix ~/.npm-global) i dodanie jego bin do PATH lub użycie nvm, który automatycznie instaluje pakiety globalne w katalogu domowym użytkownika.

Jak utrzymać działanie Gemini CLI po rozłączeniu się?

Należy uruchomić proces wewnątrz tmux. Proces uruchomiony z powłoki SSH zostaje przerwany po utracie połączenia, ponieważ jest procesem potomnym tej powłoki; tmux uruchamia powłokę na odłączonym serwerze, który działa po rozłączeniu. Należy użyć tmux new -A -s gemini, uruchomić gemini wewnątrz, odłączyć się za pomocą Ctrl-b d, a następnie ponownie połączyć się za pomocą tmux attach -t gemini.

Czy bezpieczne jest uruchamianie Gemini CLI na serwerze produkcyjnym?

Wymaga to zachowania ostrożności, ponieważ agent z dostępem do powłoki może wykonywać wszystkie operacje, na które uprawniony jest użytkownik, w ramach którego został uruchomiony. Należy uruchamiać narzędzie jako dedykowany użytkownik bez uprawnień sudo, nie przechowywać poświadczeń produkcyjnych na tej maszynie, unikać automatycznego zatwierdzania --yolo oraz używać --sandbox (Docker lub Podman) w celu izolacji wywołań narzędzi od hosta. Uprawnienia konta, pod którym działa proces, są ważniejsze niż jakakolwiek ustawiona flaga.

Czy należy otwierać porty w firewallu dla Gemini CLI?

Nie. Jest to klient wykonujący połączenia wychodzące HTTPS do API Google, zatem wymaga otwartego portu 443 dla ruchu wychodzącego, ale nie wymaga otwierania portów przychodzących. W przypadku użycia tunelu OAuth, przypisany port callback (np. 8085) działa na localhost i jest dostępny poprzez przekierowanie SSH, a nie przez otwarty port przychodzący. Należy zachować restrykcyjne ustawienia dla ruchu przychodzącego.