Ne confruntăm aici cu o problemă: la restartarea router-ului, configurarea adițională se va pierde. În plus, softul acestuia nu permite adăugarea unor script-uri care să se execute la bootare și nici modificarea celor existente. Vom presupune că varianta schimbării firmware-ului (variantă care presupune riscul transformării router-ului într-o bucată de plastic bună de aruncat la gunoi, în cel mai rău caz) nu ne interesează, astfel că trebuie să transmitem totuși comenzile din exterior, prin telnet. Am presupus din capul locului că avem în rețea o mașină care rulează tot timpul, identificată prin $server_ip; adresa router-ului în rețea este $router_ip.

Automatizarea transmisiei de comenzi de la server către router se va face în două etape: prima, conceperea unui script care să comunice cu router-ul și a doua, verificarea la momente de timp prestabilite dacă regulile de NAT Loopback sunt în tabelă.

1.Script-ul de introducere a regulilor în NAT-ul router-ului

Pentru a putea comunica cu router-ul, trebuie în primul rând să știm cum va arăta shell-ul în sesiunea de telnet cu utilizatorul. De exemplu, pe modem-ul subsemnatului, ZTE931, prima dată se va cere user-ul și parola prin linii de forma „Login: ” și „Password: ”. Apoi va fi afișat un shell identificat prin string-ul „> ”, iar după ce introduc comanda „sh” va fi afișat un alt shell, dat de „#”. Apoi, după fiecare comandă eu voi aștepta „#” de la modem.

Această comunicație poate fi automatizată folosind utilitarul expect, a cărui pagină de manual vă recomand să o consultați. Script-ul se va rula într-un shell special; se așteaptă răspunsuri de la o entitate folosind comanda expect, iar răspunsurile se trimit cu send. Mai concret, script-ul de update al tabelei NAT al router-ului va arăta astfel:

#!/usr/bin/expect -f
spawn telnet $router_ip #deschid sesiunea telnet
expect "Login: "
send -- "admin\r"
expect "Password: "
send -- "passgoeshere\r"
expect "> "
send -- "sh\r" #deschid shell pentru comenzi
expect "#"
send -- "iptables -t nat -A PREROUTING -d $external_ip -p tcp --dport 80 \
      -j DNAT --to $server_ip; iptables -t nat -A POSTROUTING -d $server_ip \
      -s 192.168.0.0/24 -p tcp --dport 80 -j SNAT --to $router_ip"
expect "#"
send -- "exit\r" #inchiderea sesiunii
expect "> "
send -- "exit\r"

Rularea acestui script bash/expect va substitui deschiderea unei sesiuni interactive și introducerea manuală a comenzilor de către utilizator. Script-ul poate fi executat de pe oricare mașină din rețeaua internă, după restartarea router-ului. Vom presupune că am numit acest script natloop și l-am salvat pe server-ul având adresa $server_ip, în directorul /router.

2.Verificarea automată a existenței NAT Loopback

Această problemă poate fi rezolvată în mai multe moduri. Unul din aceste moduri e chiar folosirea expect pentru verificarea tabelei NAT și update în cazul în care regulile nu există. Dar din moment ce am presupus că rezolvăm forward-ul către un server web, vom da o soluție un pic mai simplă: am spus că în cazul în care router-ul nu satisface NAT Loopback pe portul 80, vom fi direcționați către interfața web a acestuia. Un wget pe $router_ip (sau pe $external_ip, atunci când nu există NAT Loopback) va întoarce cel mai probabil un cod de eroare 401 (forbidden, deoarece nu au fost specificate user-ul și parola pentru sesiune). În schimb, dacă iau $nume_domeniu cu wget, voi primi 200 (eventual după câteva redirectări). Codul script-ului pingip (nume ales complet aleator, salvat probabil tot în /router) este următorul:

#!/bin/bash
mesaj=`wget $adr_domeniu 2>&1 | grep -i "HTTP request" | tail -n 1 | cut -d " " -f6`
if [ $mesaj != 200 ] ; then
    echo "$(date) $mesaj Failed" >> /router/nat.log
    /router/natloop
else
    echo "$(date) $mesaj Merge" >> /router/nat.log
fi

Vom diseca întâi prima linie, care are rolul de a lua efectiv codul întors de cererea HTTP și a-l salva în variabila $mesaj. Practic, generez un flux de string-uri, executând wget pe una din adresele web externe ale server-ului și redirectând stderr către stdout. Acest flux îl filtrez cu un grep (doresc să știu doar codul întors de pagină, iar acesta are în față „HTTP Request”) și iau ultima linie, care va conține cel mai probabil ori 200 ori 401. Împart linia în coloane (după spații) folosind cut și iau a șasea coloană, care reprezintă codul propriu-zis.

Apoi tot ce fac este să verific dacă am un cod diferit de 200 și să rulez natloop în acest caz. Pentru a monitoriza activitatea script-ului, îl pun să scrie timestamp-ul și un mesaj (cod plus stare) într-un fișier pentru logging. Ce mai rămâne este adăugarea unei linii în /etc/crontab, pentru a executa script-ul nostru la anumite intervale de timp (eu l-am pus să facă verificarea la fiecare cinci minute, de exemplu).

Trebuie remarcat că e posibil ca acest exercițiu de scripting să nu dea întotdeauna rezultate corecte. Problema în sine e destul de complicată, deoarece presupune interdependența mai multor noduri din rețea (chiar și așa, putând fi complicată și mai mult în funcție de diverși factori). Personal, sugerez cititorului să înțeleagă și să se documenteze bine înainte să ruleze oricare din comenzile menționate aici (e de ajuns un comment și voi oferi lămuriri suplimentare dacă e nevoie). De asemenea, dacă cineva vine cu o soluție mai bună, sunt numai ochi.

Să presupunem că $client_ip dorește să acceseze $external_ip – sau un nume de domeniu asociat IP-ului, pe care îl vom nota cu $nume_domeniu – pe portul 80. Ce se va întâmpla în acel moment? Dacă router-ul dispune de NAT Loopback (și are facilitatea activată), atunci el va face forwardarea din interior către $server_ip, interpretarea acestuia fiind „$client_ip, deși este din interiorul rețelei, vrea să acceseze server-ul intern ca și cum s-ar fi conectat din exteriorul rețelei”. În caz contrar, router-ul nu va face forwardarea, ci va răspunde la fel ca în cazul în care este accesat pe $router_ip:80, deci va interpreta cererea astfel: „$client_ip dorește să se conecteze la mine pe portul 80”.

Anumite routere, cum ar fi modelele WRT54G de la Linksys pot să facă NAT Loopback (eventual cu firmware-ul DD-WRT instalat). Alte routere/modem-uri fac asta implicit (fără ca utilizatorul să poată specifica alt comportament), iar altele nu știu deloc să facă NAT Loopback, de exemplu modem-urile VDSL de la Romtelecom (de acestea din urmă lovindu-se subsemnatul). Există câteva workaround-uri posibile pentru ca un site din rețeaua internă să poată fi accesat :

1. Modificarea fișierului “hosts”: soluție viabilă pentru un server care nu găzduiește un număr mare de domenii și pentru o rețea cu un număr mic și fix de calculatoare (Atenție! Pentru clienți interni mobili: laptop-uri, netbook-uri etc., soluția poate cauza probleme la conectarea ulterioară din exterior). Pe mașina (sau mașinile, presupunând că sunt mai multe) client, în /etc/hosts (diverse variante Unix) sau în windows\system32\drivers\hosts se va seta un alias de forma:

   $server_ip $nume_domeniu

   Unde $nume_domeniu este numele domeniului pe care dorim să îl accesăm. Se va adăuga câte un astfel de alias pentru fiecare domeniu hostat de către mașina server.

2. Configurarea unui server DNS, soluție destul de complicată încât să nu o explic aici. Pe scurt, se poate configura un server de nume special pentru rețeaua internă, care să directeze cererile pentru domeniile locale către $server_ip și să rezolve celelalte cereri normal. Pentru asta însă, toate mașinile din rețeaua internă trebuie configurate în așa fel încât să rezolve toate cererile NS prin acel server.
3. (pentru modem-uri) Configurarea în bridge cu un router capabil de NAT Loopback sau (pentru routere) înlocuirea cu un router capabil de NAT Loopback. Totuși, dacă soluția asta ar fi fost așa simplă, nu începeam articolul de față.
4. (pentru routere/modem-uri cu Linux/Unix și iptables) Configurarea iptables în interfața router-ului: soluția la care a recurs subsemnatul, asta fiindcă, pur întâmplător, modem-ul Romtelecom are un firmware bazat pe Busybox, un distro de linux pentru dispozitive embedded, accesibil prin telnet. În acest caz, documentația iptables menționează o metodă interesantă de configurare a NAT-ului (pentru versiunea 2.4 a kernel-ului de linux, dar aparent funcționează și pe 2.6): se face forwardarea prin NAT a tuturor cererilor venite din rețeaua internă către $server_ip prin modificarea în chain-ul PREROUTING a adresei destinație și, pentru ca pachetele să știe pe unde să se întoarcă, schimbarea în POSTROUTING a adresei sursă (inițial $client_ip) cu adresa router-ului. Cel puțin teoretic, router-ul ar trebui să știe să intermedieze conexiunea între client-ul intern și server. În mai puține cuvinte, comenzile de iptables sunt:

   $ iptables -t nat -A PREROUTING -d $external_ip -p tcp --dport 80 -j DNAT --to $server_ip
   $ iptables -t nat -A POSTROUTING -d $server_ip -s 192.168.0.0/24 -p tcp --dport 80 \
    -j SNAT --to $router_ip #se inlocuieste 192.168.0.0/24 in functie de retea

Primele două metode scot complet router-ul din ecuație. Astfel, dacă se întâmplă să schimbăm router-ul cu altul, această modificare nu ar trebui să afecteze cu nimic configurația creată anterior. A treia metodă e cea mai radicală, rezolvă cele mai multe probleme, dar este și cea mai scumpă.

Ultima metodă ar trebui să transforme router-ul nostru problemă într-unul capabil să facă NAT Loopback. Singura mare problemă este aceea că cele două comenzi nu sunt persistente. La fiecare restartare a router-ului, trebuie să ne conectăm prin telnet la acesta și să dăm copy/paste la cele două comenzi, fapt ce poate deveni destul de iritant la un moment dat (ce ne facem dacă suntem în concediu și colegii vor să acceseze un site de pe server-ul intern?).

În partea a doua a tutorial-ului vom discuta despre automatizarea task-ului de updatare a tabelei de NAT pe un modem/router cu Busybox (aceasta putându-se generaliza și pentru alte distribuții de Linux).