SSH tunelování do místní sítě

Pár užitečných příkazů co používám, když se potřebuji připojit do firmy na vzdálenou plochu (RDP) nebo SSH nějakého počítače či serveru v místní síti za NATem.

Stačí veřejná IP adresa a na firewallu a DHCP serveru přesměrovaný SSH port na nějaký linuxový server v místní síti, osobně mi k tomu slouží obyčejné Raspberry Pi kde mám SSH na nestandardním portu  a přes to už dělám zbylou magii. Upozorňuji, že sám používám i na svém PC Linux :)

Vzdálená plocha (RDP – Remote Desktop)

Pro různé firemní Windows počítače (RDP port 3389) když potřebuju dělat vzdálenou správu je prima Remmina, protože tam lze funkci SSH tunelu rovnou integrovat v profilu pro připojení. Mám tak jednoduše pro jednotlivá PC profil pro přímé připojení z LANu a druhý pro připojení zvenčí přes SSH.

SSH

Na firemní síti běží různé linuxové servery vykonávající dílčí věci: jeden co zajišťuje RADIUS autentikaci uživatelů WiFi sítě (WPA2-Enterprise) přes klientské certifikáty, a další co dělá pravidelné snapshoty celého dokumentového serveru ownCloud.

Všechny linuxové servery obsahují můj SSH RSA veřejný klíč v ~/.ssh/authorized_keys takže pro připojení už není vyžadováno heslo.

.bash_aliases

~/.bash_aliases je fajn konfigurační soubor, kam si sypu konkrétní příkazy, abych připojování na různé servery měl zvládlé jedním příkazem.

Příklad 1: připojení na to Raspberry Pi co slouží jako brána pro přístup do sítě dál, předpokládá se že veřejná IP adresa je namapovaná na doménu example.com a SSH server je pro svět vidět na portu 50000, ale v místní síti i na běžném portu 22:

alias norbu='ssh -p 50000 pi@example.com'

alias norbulocal='ssh pi@norbu.local'

Spuštění bash terminálu načte tyto aliasy.

  • v LANu napíšu „norbulocal“ (přes mDNS (Avahi/Bonjour) se mi sama zjistí vnitřní IP adresa z názvu norbu.local kdy „norbu“ je hostname)
  • Kdekoli v internetu napíšu do terminálu jen „norbu“

Příklad 2: Server na kterém běží FreeRADIUS server pro autentikaci WiFi uživatelů, přístupný už jen z místní sítě:

alias radius='ssh -A -p 50000 -t pi@example.com ssh brozkeff@radius.local'
alias radiuslocal='ssh brozkeff@radius.local'

Ekvivalentně, příkazem „radiuslocal“ se do terminálu serveru připojím z LANu a „radius“ zvenčí. Parametr -t zajistí vytvoření pseudo-tty a spuštění příkazu dalšího SSH řetězově za sebou; parametr -A navíc předá autentifikaci pomocí stejného RSA SSH klíče, aby se celé domino vůbec neptalo na heslo.

Příklad 3: Snapshoty záloh dokumentového serveru

alias babylonbackups='ssh -A -p 50000 -t pi@example.com ssh -p 30022 brozkeff@localhost'
alias babylonbackupslocal='ssh -p 30022 brozkeff@norbu.local

Tady to už je super-komplikované schéma způsobené tím, že zálohovací stroj je VirtualBoxová VPSka běžící momentálně provizorně na počítači, který vůbec nemá Ethernetovou konektivitu a jede momentálně jen na WiFi a daná wifi karta neumí pořádně udělat režim síťového mostu, aby si VPSka mohla vyžádat vlastní IP adresu ve stejném LANu jako hostitelský stroj. Takže chudák VPSka jede v dalším NATu VirtualBoxu a je nepřístupná i z místní sítě. Proto na ní je systemd služba, která spouští vzdálené přesměrování portu (SSH remote port forwarding) na již známé Raspberry Pi pomocí tohoto systemd unitu (inspirováno tímto návodem):

 

[Unit]
Description=RPi norbu Reverse SSH Service
ConditionPathExists=|/usr/bin
After=network.target
 
[Service]
User=sshtunnel
ExecStart=/usr/bin/ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -R 30022:localhost:22 babylonbackups@norbu.local
RestartSec=3
Restart=always
[Install]
WantedBy=multi-user.target

 

Tahle služba se spouští po startu VPS čímž se (opět pomocí SSH klíčů) připojí na Raspberry a svůj vlastní SSH server tak exponuje do místní sítě na IP adrese Raspberry (norbu.local), ale na portu 30022; v případě přerušení spojení se bude snažit připojovat znovu a znovu donekonečna.

Výše uvedený alias pak už dělá jen to, že v místní síti se připojuje na to Raspberry na přesměrovaném portu, čímž se ve skutečnosti otevře SSH shell té VPSky uvězněné v NATu VirtualBoxu; pro přístup z internetu se pak provede připojení na Raspberry s využitím stejného řetězení jako v druhém příkladu.

Sice je to prasácké řešení, ale funguje to a snad bude do doby, než zálohovací VPSka bude zase připojená normálně kabelem a bude mít vlastní LAN IP adresu bez dvojitého NATu :) Pro ty, kterým vstávají vlasy hrůzou na hlavě při pomyšlení, že zálohování dokumentového serveru dělá VPSka připojená přes WiFi a 2 za sebou jdoucí NATu, mohu uklidnit, že se jedná o asi třetí volitelnou zálohu sloužící jen k držení hodně starých snapshotů. Samotný dokumentový server má sám o sobě denní ZFS snapshoty 14 dní zpětně, lokální mirroring na NAS a k tomu všemu jsou data dokumentového serveru mnohonásobně replikována na většině firemních počítačů, kde běží synchronizační klienti… takže ani kdyby na týden tenhle další level zálohy nefungoval, tak se vůbec nic neděje a dlouhou dobu vše fungovalo vesele i bez tohoto řešení navíc. Tento příklad navíc ilustruje, že lze jakýkoli běžný kancelářský počítač s dostatečnou diskovou kapacitou kde běží Windows, procesor podporuje virtualizaci a je dostatek RAM, využít i k paralelnímu běhu headless linuxové VPSky, která může využívat volné místo na disku třeba k zálohování jiného serveru, a tohle celé může fungovat i pokud je počítač připojen jen přes WiFi.

Tolik dnešní postřehy kam se lze z Linuxu protunelovat :)

 

Autor

Martin

Pracuji jako ajťák a grafik na volné noze, zejména ale pro brněnskou firmu vyrábějící ekodrogerii. Dále působím v brněnském systému místní směny Rozleťse, Českém zahrádkářském svazu, České psychedelické společnosti, spolku Archetypal a Mezinárodní komunitě dzogčhenu. Chcete mě podpořit? BTC: 37mf2FJR26Ce3DxMkocukJDgB1eVjasnZB, příp. PGP podepsané adresy dalších kryptoměn.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *