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).