Konsola ratunkowa OVH nie obsługuje schowka — zero wklejania. Ten poradnik pokazuje, jak bezpiecznie przejść na SSH przez Tailscale, nie psując przy tym istniejącego przekierowania ruchu do serwera domowego, i jak dorzucić do tego HTTPS.
Awaryjna konsola QEMU/KVM w panelu OVHcloud to podgląd ekranu VPS-a na żywo — jak fizyczny monitor podłączony do serwera. Nie ma tam obsługi schowka, więc każdą komendę trzeba przepisać ręcznie. OVHcloud sam rekomenduje zarządzanie serwerem przez SSH.
Potrzebny, zanim spróbujesz połączyć się z zewnątrz.
tailscale ip -4
Dopiero stąd zadziała normalne wklejanie: Ctrl+Shift+V albo prawy przycisk myszy.
ssh debian@100.x.x.x
Prawdziwy serwer stoi w domu. VPS ma publiczny adres IP i tylko przekazuje ruch dalej przez Tailscale, korzystając z reguł NAT/DNAT. To dlatego zmiana reguły w jednym miejscu potrafi zepsuć coś zupełnie innego.
Pierwszy odruch to dodanie wyjątku dla ruchu wchodzącego przez tailscale0. Brzmi logicznie, ale w tej architekturze ruch od Ciebie wcale nie przychodzi tym interfejsem — przychodzi publicznym adresem VPS-a. Efekt: reguła nic nie chroni, a osobny port do samego VPS-a i tak trzeba dorobić inaczej.
Nie zadziała dla ruchu przychodzącego publicznym interfejsem VPS-a — a o taki ruch tu chodzi.
sudo iptables -t nat -I PREROUTING 1 -i tailscale0 -p tcp --dport 22 -j ACCEPT
Działa tylko, gdy łączysz się już przez sieć Tailscale — nie z zewnątrz.
sudo iptables -t nat -I PREROUTING 1 -i tailscale0 -p tcp --dport 2222 -j REDIRECT --to-ports 22
Port 22 przez Tailscale nadal prowadzi do serwera domowego — to się nie zmienia. Nowy port ma za zadanie dać dostęp wyłącznie do samego VPS-a, równolegle, bez ruszania istniejącego przekierowania.
Timeout na porcie 2222 może mieć kilka przyczyn: komputer nie jest w tym samym Tailnecie, brak reguły dla właściwego interfejsu, albo usługa SSH w ogóle nie nasłuchuje tam, gdzie myślisz. Sprawdź to po kolei, zamiast zgadywać kolejną regułą.
Jeśli komenda nie istnieje — klient Tailscale nie jest zainstalowany albo uruchomiony.
tailscale status
Odpowiedź pong potwierdza, że oba urządzenia widzą się w Tailnecie.
tailscale ping 100.88.8.12
Potwierdza, że usługa SSH żyje i jest widoczna na porcie 22 na serwerze.
sudo ss -ltnp | grep ':22'
Pokazuje kolejność i cel każdej reguły PREROUTING — kluczowe przy kilku regułach naraz.
sudo iptables -t nat -L PREROUTING -n -v --line-numbers
Nie dodawaj kolejnej reguły "na próbę", zanim nie zobaczysz wyników powyższych czterech komend. Reguły NAT wykonują się w kolejności — jedna nietrafiona reguła wcześniej w łańcuchu potrafi ukryć efekt każdej kolejnej.
Zanim przejdziesz do poprawnej reguły, warto zobaczyć dokładnie, dlaczego wcześniejsza próba nie mogła zadziałać. To jedno zdanie tłumaczy resztę tego poradnika.
Twoje połączenie z komputera dociera do VPS-a jego publicznym interfejsem — nie przez tailscale0. Reguła celująca w ten interfejs nigdy nie zobaczy tego ruchu. Dodatkowo ogólna reguła DNAT wysyłała port 2222 od razu do serwera domowego, gdzie nic na nim nie nasłuchiwało — stąd timeout.
sudo iptables -t nat -I PREROUTING 1 -i tailscale0 …
REDIRECT na -d 57.128.255.40 przechwytuje ruch lokalnie, do samego VPS-a, zanim zadziała ogólne przekierowanie do domu — dokładnie tam, gdzie ruch naprawdę wchodzi.
sudo iptables -t nat -I PREROUTING 1 -d 57.128.255.40 …
Skoro łączysz się z komputera przez publiczny adres VPS-a, reguła musi celować w ten adres — nie w tailscale0. REDIRECT kieruje ruch lokalnie, do samego VPS-a, zanim zadziała ogólne DNAT do domu.
Musi znaleźć się przed ogólną regułą DNAT do serwera domowego, stąd numer 1.
sudo iptables -t nat -I PREROUTING 1 -d 57.128.255.40 -p tcp --dport 2222 -j REDIRECT --to-ports 22
Osobny port, osobne polecenie — nie zastępuje dotychczasowego dostępu do domu.
ssh -p 2222 debian@57.128.255.40
To samo polecenie co zawsze — nadal prowadzi tam, gdzie prowadziło.
ssh debian@57.128.255.40 # nadal → serwer domowy
Reguła iptables to jedno, a osobna zapora (np. Network Firewall w panelu OVHcloud) to drugie — port trzeba dopuścić w obu miejscach.
# sprawdź: panel OVHcloud → Network Firewall → dopuść TCP 2222 # oraz lokalny firewall na samym VPS (ufw / iptables INPUT)
Gdy SSH do VPS-a już działa wygodnie, ten sam mechanizm DNAT przekazuje ruch HTTPS z publicznego adresu VPS-a na konkretny port serwera domowego przez Tailscale.
Ruch trafiający na publiczny adres VPS-a na porcie 443 zostaje przekazany na wskazany port serwera domowego.
sudo iptables -t nat -I PREROUTING 1 -d 57.128.255.40/32 -p tcp --dport 443 -j DNAT --to-destination 100.96.49.10:9443
Powinieneś zobaczyć wpis kierujący ruch dokładnie na 100.96.49.10:9443.
sudo iptables -t nat -L PREROUTING -n -v --line-numbers tcp dpt:443 to:100.96.49.10:9443
Szybki test bez otwierania przeglądarki.
curl.exe -Iv https://57.128.255.40/
Ten sam Network Firewall OVHcloud i lokalny firewall na VPS, który mógł blokować port 2222, tak samo potrafi zablokować 443 — sprawdź oba miejsca, zanim zaczniesz szukać błędu w regule DNAT.
# panel OVHcloud → Network Firewall → dopuść TCP 443 # na VPS: sudo ufw status (albo iptables -L INPUT -n -v)
Reguły iptables domyślnie żyją tylko w pamięci. Po restarcie VPS-a — czy to zaplanowanym, czy awaryjnym — wszystko, co tu ustawiłeś, zniknie, jeśli nie zapiszesz reguł na dysk.
Podczas instalacji potwierdź zapis reguł IPv4, gdy zapyta instalator.
sudo apt update sudo apt install iptables-persistent
Zapisuje bieżący stan tablicy NAT, żeby przetrwał restart.
sudo netfilter-persistent save
ssh debian@57.128.255.40 nadal prowadzi na serwer domowy, tak jak zawsze.
ssh -p 2222 debian@57.128.255.40 daje wygodny dostęp z kopiuj-wklej, zamiast konsoli ratunkowej.
Port 443 z publicznego adresu trafia do właściwego portu na serwerze domowym.
netfilter-persistent save wykonane po ostatniej zmianie — nie przed nią.
sudo iptables -t nat -L PREROUTING -n -v --line-numbers sudo ss -ltnp | grep -E ':(22|2222|443)' systemctl status netfilter-persistent --no-pager -l
1) Zweryfikuj nowe reguły zanim zapiszesz je na stałe.
2) Utrzymuj dwa oddzielne, działające dostępy SSH (port 22 do domu, port 2222 do VPS-a) — jeśli jeden padnie, drugi zostaje ratunkiem.
3) Po każdej kolejnej zmianie reguł uruchom netfilter-persistent save ponownie — stary zapis nie aktualizuje się sam.
4) Trzymaj gdzieś zanotowaną pełną listę reguł (iptables -t nat -L PREROUTING -n -v --line-numbers) — przyda się, jeśli kiedyś trzeba będzie odtworzyć konfigurację od zera.