Fixam un bug la un proiect care utilizează Elasticsearch pentru stocarea datelor, pe mașina locală nu am o instanța de Elasticsearch iar fără date nu aveam cum sa fixez problema. Pentru a mă conecta remote la mașina unde ruleaza baza de date și a expune portul remote pe local am utilizat un tunel ssh.
Local forwarding:
Exemplu 1:
Pe mașina la care dorim sa ne conectăm, pe portul 80, ascultă serviciul cu care dorim să comunicăm, dorim să expunem acest serviciu pe portul local 3000
ssh -L 3000:localhost:80 <user>@<remote-machine>
Exemplu 2:
Ne aflăm intr-o rețea în care nu este permisă accesarea siteului https://dan.iftodi.com. Pentru a trece peste impediment, vom utiliza ssh:
ssh -L 9000:dan.iftodi.com:80 <user>@<remote-machine>
Aceasta comanda spune ca facem forward la portul local 9000 catre domeniul dan.iftodi.com pe portul 80 ( portul 80 este portul default pentru http ).
Tehnica poate fi utilizată atunci cand este necesar sa lucram cu servicii care sunt disponibile doar din localhost, ne fiind expuse public.
Remote forwarding:
Partea opusă pentru local forwarding este remote forwarding. Imagineză-ți că lucrezi la o aplicație Java și dorești să îi arăți prietenului tău cum funcționează, din păcate ISP de la care ai internet nu îți oferă adresa IP publică sau adresa publică indică catre altă mașina din rețeaua în care te afli și nu ai access pe router ca să faci modificari.
ssh -R 80:localhost:4200 <user>@<remote-machine>
Sintaxa este similara cu forwardingul pentru portul local doar ca trebuie să utilizezi parametrul -R. 80 – e portul pe care remote-machine va asculta, localhost – e mașina ta, pe portul 4200 ascultă aplicația scrisa care vrei ca prietenul tău să o vadă.
Doar o singură nuață pentru remote forwarding, ssh în mod implicit nu permite redirecționarea remote a porturilor, pentru a activa adaugă în fisierul
sudo vim /etc/ssh/sshd_configlinia ( asigura-te că o adaugi o singură dată ):
GatewayPorts yesrestartează ssh dameon:
sudo service ssh restart