Soluţii - PC Magazine Romania, Septembrie 2004

LINUX - Stând în intersecţie

Răzvan Sandu

Motto:

"Îmi place să văd oameni grăbiţi. Ei înseamnă acţiune. Cel mai ciudat este că sunt grăbiţi pentru a ajunge în locul în care pot sta. Sunt grăbiţi pentru a sta cât mai repede. Statul e problema fundamentală. El emite Legile Statului. Legile Statului sunt binecunoscute de toţi cetăţenii învăţaţi cu Statul. Statul înseamnă odihnă."

Ada Milea - "Perspectiva. Statul. Curcubeu de gaze."

Abia sosit din vacanţă, deschid o revistă de TI şi îmi cad sub priviri, chiar în editorial, câteva disperate semnale de alarmă la adresa Fedora Core 2. Cică distribuţia nu este stabilă, e făcută de mântuială… Nu o folosiţi, deci, în instalări critice - va să zică, în mediul de afaceri, acolo unde "se rotesc" bani!

Doamne, chiar sunt în pericol? Eu am, totuşi, o reţea în funcţiune, formată din câteva sute de calculatoare, a cărei infrastructură se bazează exclusiv pe Fedora Core 2… La a doua lectură, povestea asta alarmistă îmi sună ca importanţa acordată în jurnalele de ştiri VIP-urilor dâmboviţene. (Dicţionarul zice că un VIP - adică Very Important Person - este o persoană de neînlocuit, unul de ale cărui decizii depinde soarta unui număr foarte mare de oameni. Din acest motiv, îmi pot imagina uşor de ce preşedintele Statelor Unite este un VIP. Din acelaşi motiv, nu voi înţelege în ruptul capului cum altor personaje - cutărui baron local sau starletei care îmi terorizează după-amiezele petrecute în faţa teveului - li se acordă acelaşi titlu…). În cazul nostru, să fie "concurenţa" chiar atât de speriată de dezvoltarea Linux-ului, încât să se fi apucat să "facă valuri" chiar în revistele de specialitate?

Dar să lăsăm asta, prieteni, şi să vă povestesc ceva…

Din vremurile vechi

Ca administratori pe reţele mai mari sau mai mici, nu se poate să nu vă fi ciocnit de serviciul DNS şi să nu îi cunoaşteţi utilitatea. Vechile reţele de firmă din anii ´90, bazate pe Windows 98, se "mişcau" atât de greu şi deveneau rapid supraaglomerate tocmai pentru că lipsea acest serviciu, iar staţiile din reţea "se descopereau" una pe alta prin intermediul broadcasting-ului… Mai târziu, un vechi vis al utilizatorilor de Windows s-a împlinit: odată cu "unealta" numită Internet Sharing, a apărut posibilitatea ca mai multe calculatoare din LAN să navigheze pe Internet prin intermediul unuia singur, care dispunea de modem… Când lucrurile au început să se contureze, oamenii şi-au pus pentru prima dată serios întrebarea: ce nume ("oficial") trebuiau să poarte toate aceste maşini (gateway-ul cu modem şi staţiile interne) ca să poată naviga fără a "jena" pe cineva din Internet? Problema denumirii staţiilor, aparent banală, a devenit mai importantă ca oricând…

În lumea Microsoft, utilizatorii s-au văzut, brusc, confruntaţi cu o problemă.

Tradiţional, maşinile Windows 98 erau "botezate" cu un nume NETBIOS, case-insensitive, de maximum 15 caractere. Este vorba de acel nume pe care îl vedeţi într-o reţea LAN, atunci când daţi un dublu-click pe icon-ul Network Neighborhood. El se poate seta foarte uşor, făcând click-dreapta pe acelaşi icon şi alegând "Properties". Pe reţeaua locală, lua astfel naştere un spaţiu de nume flat (neierarhizat) - mulţimea numelor de staţii din acea reţea.

Pentru nevoi practice la nivelul unei reţele locale, era absolut suficient, cu condiţia să nu existe două calculatoare cu acelaşi nume. Suprapuneri nu apăreau nici în cazul în care două LAN-uri diferite erau interconectate printr-un router: broadcast-ul NETBIOS nu "trece" prin router, astfel încât cele două reţele rămâneau separate chiar şi în cazul în care două staţii din LAN-uri diferite purtau aceeaşi denumire.

Lucrurile s-au complicat însă odată cu migrarea către folosirea "NETBIOS over TCP/IP", care este metoda recomandată de funcţionare în Windows 2000 şi Windows XP. Routerele deveneau brusc "transparente" pentru pachete, aşa că Microsoft a trebuit să găsească o altă soluţie.

În noua configuraţie, vechiul nume NETBIOS a devenit prima parte (hostname-ul) a unui nume complet DNS, de exemplu:

numevechi.example.com

Acest nume DNS are o structură ierarhică, de arbore, care permite distingerea maşinilor numevechi.example1.com şi numevechi.example2.com. În plus, pentru rezolvarea numelor poate fi folosit acum nu broadcast-ul, ci mecanismul "clasic" DNS, bine pus la punct în lumea Unix.

Unul dintre primele lucruri pe care le află un începător este că, într-o reţea, adresele sunt asignate interfeţelor şi nu maşinilor. O maşină-router, având, de exemplu, mai multe plăci Ethernet conectate la reţele diferite, va avea tot atâtea adrese IP. Acestea vor apărea în fişierul /etc/hosts ca:

127.0.0.1 localhost localhost.localdomain
192.168.1.7 nume.example.com
192.168.9.3 nume.example.com 
192.168.10.3 nume.example.com

(prima adresă/interfaţă este cea loopback).

Să învăţăm să fim făţarnici

Dar ce se întâmplă cu un router, conectat în reţeaua A şi în reţeaua B, care rulează serviciul DNS şi care trebuie să răspundă diferit interogărilor sosite din cele două reţele?

Exemplul clasic este maşina Linux care face NAT/masquerading şi prin intermediul căreia vă conectaţi la Internet. Ea are două plăci de reţea: placa orientată către Internet primeşte adresa IP publică, care v-a fost alocată de către ISP, iar placa "interioară" va avea o adresă privată, (să zicem 192.168.1.1), din aceeaşi clasă ca şi staţiile de lucru din reţeaua locală. Un utilizator oarecare, situat "afară", în Internet, nu "vede" absolut nimic în interiorul reţelei voastre, "prin" gateway, ci i se pare că acolo se găseşte un singur computer, având adresa IP publică.

Să presupunem acum că pe acest router, numit gateway.example.com, rulează şi serviciul DNS, care va răspunde atât interogărilor din exterior, cât şi celor din interior. Unui client din LAN, care întreabă "cine este gateway.example.com?",

i se poate răspunde atât cu adresa IP publică cât şi cu cea privată, 192.168.1.1. Unui alt client, din Internet, care va pune aceeaşi întrebare, trebuie să i se răspundă numai cu adresa IP publică - nu are sens să primească adresa 192.168.1.1, întrucât pe aceasta nu o poate "vedea"/accesa din exterior!

Până nu demult, soluţia acestei probleme era destul de complicată: maşina trebuia să ruleze două servere DNS separate (în cazul Linux, programul bind, care implementeză serviciul DNS named), configurate astfel încât fiecare să deservească clienţii din reţelele respective, oferindu-le răspunsurile potrivite. Începând cu versiunea 9, programul bind al Internet Software Consortium (ISC - http://www.isc.org) simplifică lucrurile, în sensul că un singur server DNS poate deservi toţi clienţii.

Din discuţia noastră despre serverul DNS, vă mai amintiţi, desigur, că setările acestuia sunt făcute în fişierul /etc/named.conf şi în fişierele de zonă, care stau în directorul /var/named. Primul fişier controlează parametrii generali de funcţionare ai serviciului, iar fişierele de zonă conţin tabelele de înregistrări propriu-zise, care realizează conversia numelor (de tipul www.example.com) în adrese IP şi invers. Să presupunem că zona despre care discutăm este example.com, iar informaţia despre ea este cuprinsă în fişierul example.com.zone. Iată un fişier /etc/named.conf extras de pe sistemul meu Linux:

// named.conf
options {
       query-source address * port 53;
       directory "/var/named";
};
controls {
       inet 127.0.0.1 allow { localhost; } 
       keys { rndckey; };
};
zone "." {
       type hint;
       file "named.ca";
};
zone "localhost" {
       allow-update { none; };
       type master;
       file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" {
       allow-update { none; };
       type master;
       file "named.local";
};
zone "example.com" {
  allow-update { none; };
       type master;
       file "example.com.zone";
};
include  "/etc/rndc.key";

În cazul pe care îl studiem, ceea ce dorim este ca, atunci când este interogat, serverul nostru DNS să furnizeze o anumită informaţie unor clienţi (cei din reţeaua "externă", Internetul) şi o altă informaţie celorlalţi (cei din reţeaua internă, LAN-ul). Vom folosi în fişierul /etc/named.conf directiva view - ultima secţiune a acestui fişier devine:

...
view "intern" {
match-clients {192.168.1.0/24};
zone "example.com" {
  	allow-update { none; };
       	type master;
       	file "example.com.zone.intern";
};
};
view "extern" {
     match-clients {any};
zone "example.com" {
  	allow-update { none; };
       	type master;
       	file "example.com.zone.extern";
};
};
...

Observaţi că în interiorul unei directive view este cuprinsă informaţia despre zona example.com. view foloseşte opţiunea match-clients drept criteriu de selecţie: toţi clienţii care îndeplinesc acest criteriu vor primi răspunsuri conform celor spuse în interiorul directivei. În cazul nostru, toţi clienţii din LAN-ul 192.168.1.0/24 vor "vedea" fişierul example.com.intern, iar ceilalţi (adică cei din Internet) fişierul example.com.extern. Desigur, informaţia conţinută în fişierele example.com.intern şi example.com.extern este diferită, după necesităţi, iar ordinea directivelor view în fişier este importantă: de sus in jos, va fi folosită acea secţiune al cărei criteriu match-clients este îndeplinit primul.

Pentru aceia dintre voi care aţi început să folosiţi Fedora Core 2, trebuie remarcat că fişierele de configurare ale daemonului named se pot găsi şi în subdirectoarele din /var/chroot. Asta datorită faptului că Fedora Core 2 introduce, în mod standard, posibilitatea (recomandată!) a folosirii unui subdirector-rădăcină fals pentru rularea daemon-ului (chroot jail). Acest lucru nu are legătură directă cu discuţia noastră de azi - amănunte puteţi găsi în Chroot-BIND-HOWTO.

Încheiere

Configurarea corectă a unei reţele de dimensiuni medii sau mari nu este o problemă simplă, de aceea sper că am reuşit să vă ofer soluţia unei probleme, aparent minore, cu care v-aţi mai întâlnit.

Bineînţeles, aştept cu plăcere întrebările şi părerile voastre la [email protected].