Differences
This shows you the differences between two versions of the page.
|
rl:labs:08:contents:01 [2020/12/01 10:52] iulia.florea |
rl:labs:08:contents:01 [2025/11/28 11:22] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 1. [5p] Conectare SSH folosind cheie publică ==== | + | ==== 01. [10p] Configurare translatare de adrese (MASQUERADE) ==== |
| - | Dorim să realizăm o sesiune securizată shell la distanță (//remote shell//). | + | Epuizarea adreselor IPv4 în cadrul rețelelor curente a condus la folosirea de adrese IP din clase private (de ex. ''192.168.0.0/24''). Pe lângă comunicația dintre stațiile unei rețele, dorim și accesul la Internet al acestora. De aceea s-a introdus conceptul de translatare de adrese (NAT: //Network Address Translation//) prin care mai multe stații dispun de acces la Internet folosind aceeași adresă IP rutabilă: adresa gateway-ului. Activarea translatării de adrese (NAT) pe gateway conduce la înlocuirea perechii <adresă IP sursă, port sursă> (aparținând stației) cu perechea <adresa IP gateway, port disponibil>. |
| - | <spoiler Sumar exerciții conectare SSH (dați click)> | + | Configurarea NAT pe Linux se realizează tot prin intermediul comenzii ''iptables'', la fel ca în cazul configurării firewall-ului. Dacă pentru configurarea firewall-ului foloseam tabela ''filter'' (tabela implicită a ''iptables''), pentru configurarea translatării de adrese vom folosi tabela ''nat''. |
| - | Pentru exercițiile de conectare SSH, vom urma pașii: | + | |
| - | - Conectare folosind SSH cu chei. Totul este configurat și vedem că merge. | + | |
| - | - Copiere cheie pentru conectare SSH. Cheia există și vom face apoi conectare ca mai sus. | + | |
| - | - Crearea cheie, copiere și conectare SSH. | + | |
| - | Urmăm pașii în acest fel pentru a urmări întâi comenzile de conectare, sintaxa SSH și rolul său și apoi să investigăm cum se întâmplă lucrurile în spate. | ||
| - | În cazul în care veți avea un cont pe un server și veți dori conectare SSH cu chei, veți urma doar pasul 3. | ||
| - | </spoiler> | ||
| - | Din contul ''student'' de pe stația ''red'' conectați-vă la stația ''host'' prin SSH prin rularea comenzii<code bash> | + | Astfel, pentru a activa NAT pe un server Linux executăm comanda<code bash> |
| - | student@red:~$ ssh student@host | + | root@host:~# iptables -t nat -A POSTROUTING -j MASQUERADE |
| - | [...] | + | </code> |
| - | student@host:~$ | + | În comanda de mai sus: |
| - | </code> Observați faptul că v-ați conectat direct, fără parolă, întrucât autentificarea s-a realizat folosind cheie publică. Folosiți combinația de taste ''Ctrl+d'' sau comanda ''exit'' pentru a închide sesiunea de shell la distanță. | + | * ''-t'' specifică tabela pe care se aplică regula, în cazul nostru tabela ''nat''. |
| + | * ''-A'' înseamnă adăugarea unei reguli la sfârșitul listei de reguli. | ||
| + | * ''POSTROUTING'' se referă la momentul când va fi realizat procesul de translatare de adrese: după rutare. | ||
| + | * În nomenclatura ''iptables'' acesta se numește și **lanț (chain)**. | ||
| + | * [[https://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html|Exemple de alte lanțuri: ''INPUT'', ''OUTPUT'', ''FORWARD'', ''PREROUTING'']]. | ||
| + | * ''-j'' este acțiunea ce va fi luată, iar în acest caz este ''MASQUERADE'' (acțiune simplă de translatare de adrese). | ||
| - | Cheia publică folosită la conectare este disponibilă în fișierul ''~/.ssh/id_rsa.pub''. Pentru vizualizarea cheii rulați, pe stația ''red'' din contul utilizatorului ''student'', comanda<code bash> | + | Pentru a verifica și valida regula, afișăm intrările din lanțul ''POSTROUTING'' din tabela ''nat'' folosind comanda<code bash> |
| - | student@red:~$ cat ~/.ssh/id_rsa.pub | + | root@host:~# iptables -t nat -L POSTROUTING -n -v |
| - | ssh-rsa AAAAB3NzaC1[...] student@red | + | Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) |
| + | pkts bytes target prot opt in out source destination | ||
| + | 0 0 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 | ||
| </code> | </code> | ||
| - | Un alt format de comandă SSH de conectare este cel de mai jos. Pe stația ''red'' rulați comanda<code bash> | + | Vrem să verificăm configurarea corectă a NAT. Pentru acesta vom trimite de pe stația ''red'' un pachet către ''1.1.1.1''. Pachetul va trece prin gateway (adică stația ''host'') și va fi translatat. Pe stația ''red'' rulăm comanda<code bash> |
| - | student@red:~$ ssh -l student host | + | root@red:~# ping -c 2 1.1.1.1 |
| - | [...] | + | PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. |
| - | student@host:~$ | + | From 192.168.1.2 icmp_seq=1 Destination Host Unreachable |
| - | </code> La fel, închideți sesiunea de shell la distanță prin folosirea combinației de taste ''Ctrl+d''. | + | From 192.168.1.2 icmp_seq=2 Destination Host Unreachable |
| - | La distanță, cheia publică este stocată, împreună cu alte chei publice folosite pentru conectare, în fișierul ''~/.ssh/authorized_keys''. Rulați comanda de mai jos pentru a confirma prezența cheii publice la distanță<code bash> | + | --- 1.1.1.1 ping statistics --- |
| - | student@red:~$ ssh -l student host "cat ~/.ssh/authorized_keys" | + | 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms |
| - | ssh-rsa AAAAB3N[...] student@blue | + | |
| - | ssh-rsa AAAAB3N[...] student@green | + | |
| - | ssh-rsa AAAAB3N[...] student@red | + | |
| - | ssh-rsa AAAAB3N[...] student@host | + | |
| </code> | </code> | ||
| - | Se observă că există cheia ''student@red'' în fișierul de la distanță de pe stația ''host'', deci se poate realiza autentificarea SSH pe bază de chei. | + | Observăm că nu există conectivitate de la stația ''red'' către adresa IP ''1.1.1.1''. Consultăm întreaga tabelă ''nat'':<code bash> |
| + | root@host:~# iptables -t nat -L -n -v | ||
| + | Chain PREROUTING (policy ACCEPT 2 packets, 168 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | |||
| + | Chain INPUT (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | |||
| + | Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | |||
| + | Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | 0 0 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 | ||
| + | </code> | ||
| + | Observăm că pachetele ajung în lanțul ''PREROUTING'' (înainte de rutare), dar nu ajung în lanțul ''POSTROUTING'' (după rutare). Ne gândim că este posibil să fie o problemă cu rutarea pe gateway. Verificăm dacă rutarea este activată:<code bash> | ||
| + | root@host:~# sysctl net.ipv4.ip_forward | ||
| + | net.ipv4.ip_forward = 0 | ||
| + | </code> | ||
| + | |||
| + | Într-adevăr, rutarea nu este activată. Pentru a activa rutarea pe stația ''host'' rulăm comanda<code bash> | ||
| + | root@host:~# sysctl -w net.ipv4.ip_forward=1 | ||
| + | net.ipv4.ip_forward = 1 | ||
| + | </code> | ||
| + | |||
| + | Intrăm din nou pe stația ''red'' și folosim ''ping'' pentru a testa conectivitatea la adresa IP ''1.1.1.1'':<code bash> | ||
| + | root@red:~# ping -c 2 1.1.1.1 | ||
| + | PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. | ||
| + | 64 bytes from 1.1.1.1: icmp_req=1 ttl=61 time=92.9 ms | ||
| + | 64 bytes from 1.1.1.1: icmp_req=2 ttl=61 time=81.2 ms | ||
| + | |||
| + | --- 1.1.1.1 ping statistics --- | ||
| + | 2 packets transmitted, 2 received, 0% packet loss, time 1001ms | ||
| + | rtt min/avg/max/mdev = 81.272/87.094/92.917/5.829 ms | ||
| + | </code> | ||
| + | Acum există conectivitate, lucru certificat și de prezența unor pachete în lista prelucrată pe lanțul ''POSTROUTING'':<code bash> | ||
| + | root@host:~# iptables -t nat -L POSTROUTING -n -v | ||
| + | Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) | ||
| + | pkts bytes target prot opt in out source destination | ||
| + | 2 168 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 | ||
| + | </code> | ||
