Zeroconf

Zeroconf sau Zero Configuration Networking este un proiect pentru configurarea independentă a rețelelor de calculatoare fără intervenția umană.

fundal

Grupul de lucru corespunzător al Grupului operativ de inginerie Internet a încheiat fără rezultat din cauza lipsei consensului . A lucrat din 1999 până în 2004. Obiectivele ei au fost:

Grupul de lucru a relativizat Zero ( zero ) în sensul că o configurație mică este mai bună decât nu există securitate .

În 2005, RFC 3927 a fost publicat ulterior despre configurarea automată a IPv4 în rețelele locale fără protocolul de configurare a gazdei dinamice . Acest text a fost scris de angajații Apple , Microsoft și Sun Microsystems și, de asemenea, documentează implementările anterioare ale AutoIP sau Automatic Private IP Addressing (APIPA). Conexiunile la alte rețele decât Internetul sunt excluse în toate acestea. Configurarea automată a adresei fără stat IPv6 conform RFC 4862 este mai flexibilă în acest sens.

Cel mai simplu scenariu este conectarea a două computere cu un cablu crossover . Fiecare dispozitiv caută automat o adresă IP gratuită și poate fi apoi adresată utilizând protocolul Internet (IP) la această adresă. Această sarcină nu este nouă și a fost rezolvată în mare măsură cu AppleTalk sub Mac OS și NetBIOS sub Windows . Pentru ao utiliza, totuși, trebuie să cunoașteți adresa IP a stației la distanță, motiv pentru care Zeroconf continuă să vizeze.

Alocare automată IP

Acesta este un mecanism bazat pe Protocolul de rezoluție a adresei (ARP) pentru a selecta automat o adresă IP gratuită pentru o interfață de rețea . IANA furnizează domeniul de adrese 169.254.0.0/16 în acest scop , prima și ultima 256 de adrese din acest interval fiind rezervate pentru aplicații viitoare.

Dacă un computer dorește să configureze o adresă IP locală de legătură, selectează o adresă IP aleatorie între 169.254.1.0 și 169.254.254.255. La generarea adresei IP, ar trebui incluse informații specifice computerului, cum ar fi adresa MAC a interfeței de rețea, astfel încât aceeași adresă IP să fie generată de fiecare dată, dacă este posibil (este selectată doar pseudo- aleatoriu ).

După selectarea adresei sale IP, computerul trebuie să o revendice și să testeze dacă este deja utilizat de un alt computer. Acest test trebuie efectuat înainte ca adresa IP să fie utilizată ca adresă a expeditorului în pachetele IP sau ARP și exact când este activată o interfață de rețea. Aceasta poate fi pornirea sau repornirea computerului, trezirea din modul de repaus , conectarea unui cablu Ethernet sau conectarea automată a unui computer la o rețea WLAN . Este explicit interzisă efectuarea acestei verificări periodic, deoarece aceasta ar reprezenta o risipă a resurselor rețelei, iar testul propriu-zis pentru conflictele de adrese oferă deja posibilitatea de a recunoaște pasiv și de a reacționa la posibilele conflicte.

Adresele sunt verificate pentru conflicte cu ajutorul sondelor ARP. O probă ARP este un pachet ARP în care adresa IP a expeditorului este setată la 0.0.0.0 și adresa de verificat este utilizată ca adresă IP a destinatarului.

De îndată ce computerul este gata să înceapă să verifice conflictul, acesta așteaptă un timp aleatoriu între 1 și 2 secunde și apoi trimite trei sonde ARP cu un interval aleatoriu de 1 până la 2 secunde. Dacă computerul primește un pachet ARP între începutul testului și 2 secunde după ce a fost trimisă ultima sondă ARP, în care adresa IP a expeditorului corespunde adresei IP de verificat, a fost găsit un conflict. Computerul trebuie apoi să repete această procedură cu o altă adresă IP generată.

Dacă în această perioadă se primește o altă probă ARP care conține adresa IP care urmează să fie testată ca adresă IP a destinatarului și a cărei adresă MAC expeditor nu corespunde niciunei adrese MAC ale interfeței de rețea a computerului, computerul trebuie să trimită și un o nouă adresă IP poate fi generată și verificată. Acest lucru se poate întâmpla, de exemplu, dacă două sau mai multe computere încearcă să configureze aceeași adresă link-local în același timp.

Pentru a evita furtunile ARP și astfel supraîncărcarea rețelei locale dacă există mai multe conflicte în succesiune rapidă, fiecare computer trebuie să reducă viteza cu care selectează și să verifice adrese noi la maximum o verificare pe minut după zece încercări nereușite.

Dacă computerul nu a putut găsi un conflict, a revendicat cu succes adresa IP generată. Apoi, el trebuie să facă acest lucru cunoscut, trimițând două anunțuri ARP cu un interval de 2 secunde. Un anunț ARP diferă de un sondaj ARP numai prin faptul că adresa IP link-locală recent selectată este utilizată ca adresă IP expeditor și destinatar.

Detectarea conflictelor trebuie să aibă loc permanent, chiar și după selectarea unei adrese IP utilizabile. Dacă computerul primește un pachet ARP care a fost trimis de pe alt computer și conține propria adresă IP ca adresă IP a expeditorului, există un conflict de adresă.

Computerul are acum două opțiuni, și anume să selecteze o nouă adresă IP sau să-și apere adresa IP. Acesta din urmă este de preferat dacă computerul mai are conexiuni TCP deschise. Dacă nu s-au primit încă pachete ARP care se ciocnesc, adresa este apărată de computer prin trimiterea unui anunț ARP. Cu toate acestea, dacă computerul a reușit să detecteze un conflict de adresă în ultimele câteva secunde, trebuie să selecteze o nouă adresă IP pentru a evita o buclă nesfârșită dacă două computere cu aceeași adresă IP încearcă să o apere împotriva celeilalte.

DNS multicast

DNS multicast în stiva de protocol TCP / IP
cerere DNS multicast
transport UDP
reţea IP (IPv6, IPv4)
Acces la retea Ethernet Token
ring 		FDDI ...

Problemele legate de traducerea de nume și adrese IP fără un server DNS și de a avea un mecanism disponibil pentru publicarea automată și găsirea serviciilor de rețea au fost rezumate în mod convenabil de către Grupul de lucru Zeroconf și sub forma celor două multicast fundamental independente, dar complementare reciproc. protocoalele DNS (mDNS) și DNS-Based Service Discovery (DNS-SD) puse pe hârtie.

mDNS nu este altceva decât o descriere a modului în care clienții trebuie să procedeze atunci când trimit cereri DNS către adrese de difuzare multiplă și modul în care un grup de computere se ocupă de ele, astfel încât solicitarea să fie răspunsă corect și fără o sarcină crescută în rețea. DNS-SD, pe de altă parte, specifică o convenție pentru utilizarea tipurilor de înregistrări DNS existente care permit navigarea și publicarea serviciilor de rețea cu DNS.

mDNS specifică faptul că domeniul DNS de nivel superior ".local" este link-local. Interogările și răspunsurile care au legătură cu „.local”. Similar cu adresele IP din gama 169.254.0.0/16 sau fe80 :: / 10 au sens doar în rețeaua locală. Toate interogările DNS pentru numele care se termină cu „.local”. Trebuie trimise la adresa multidifuziune mDNS (IPv4: 224.0.0.251, IPv6: ff02 :: fb, port UDP 5353) utilizând UDP și IP multidifuziune. Dacă nu este disponibil alt server DNS, cererile care nu se termină cu „.local” pot fi trimise și la această adresă.

Apropo, fiecare computer este liber să își aleagă propriul nume de computer din domeniul „.local”. Spre deosebire de alte domenii publice de nivel superior, nu există formalități, cu excepția faptului că numele computerelor care au fost deja atribuite nu ar mai trebui utilizate. Desigur, conflictele pot apărea în practică, dar inventatorii ADNm au considerat că acest lucru este foarte puțin probabil. O rezolvare a conflictelor nu este chiar deliberată, deoarece pot exista aplicații utile în cazul în care mai multe computere au același nume - de exemplu pentru partajarea încărcării sau soluții de înaltă disponibilitate .

Dacă numele de gazdă pentru o adresă IP locală de legătură urmează să fie determinat printr-o interogare DNS de mapare inversă , aceasta trebuie trimisă și la adresa multidifuziune mDNS (vezi mai sus).

Evitarea traficului de rețea redundant

Pentru a menține traficul de rețea cât mai redus posibil, inventatorii mDNS au venit cu câteva reguli de conduită pentru a preveni interogări sau răspunsuri duplicate sau chiar multiple de mDNS.

Suprimarea răspunsurilor cunoscute

O posibilitate de suprimare a răspunsurilor deja cunoscute este aceea că clientul care trimite o interogare mDNS adaugă răspunsuri deja cunoscute care pot fi găsite în cache - ul său ca înregistrări de răspuns la interogarea sa. Dacă un alt client care ar putea răspunde la interogare vede răspunsul său sugerat în lista de răspunsuri deja date și TTL (timpul de viață) este încă mai mult de jumătate din TTL obișnuit, nu mai trebuie să-l trimită. Dacă TTL este prea scăzut, celălalt client trebuie să trimită un răspuns pentru a actualiza TTL stocat în memoria cache a primului client.

Suprimarea întrebărilor duplicat

Dacă mai mulți clienți ar trimite aceeași interogare aproximativ în același timp, ar exista trafic de rețea redundant. Dacă un client intenționează să trimită o cerere și vede o cerere de la un alt client cu același conținut, acesta ar trebui să considere cererea străină ca proprie și să utilizeze răspunsul în loc să trimită propria cerere.

Suprimarea răspunsului duplicat

Dacă un server, în timp ce se pregătește să trimită un răspuns, vede un răspuns de la un alt server cu același conținut și TTL (timpul de trăire) al răspunsului străin nu este mai mic decât cel planificat, atunci ar trebui să considere răspunsul său ca fiind trimis (adică nu trimiteți propriul răspuns).

Implementări

Prima implementare a Zeroconf a fost realizată de Apple și se numește Bonjour (fost Rendezvous ). A fost integrat în Mac OS X de la versiunea 10.2 („Jaguar”, 2002) - redenumită macOS în 2016 - și Apple oferă cele mai multe programe cu funcționalități Bonjour în măsura în care are sens.

O componentă a Bonjour este proiectul mDNSResponder, care a fost publicat de Apple în cod sursă sub licența Apache. mDNSResponder implementează mDNS și DNS-SD. A fost proiectat și implementat de Apple pentru a fi portabil, astfel încât textul sursă să poată fi tradus nu numai sub Mac OS X 10.2 sau o versiune ulterioară, ci și sub Linux , FreeBSD , NetBSD , OpenBSD , Solaris , VxWorks , Mac OS 9 și Windows fără modificări.

O eroare cunoscută în implementarea mDNS de către Apple duce adesea la problema din Windows 7 că este introdus un gateway implicit de 0.0.0.0, care este utilizat înainte de gateway-ul obținut prin DHCP și, astfel, conexiunea la internet a computerului este paralizată eficient. O soluție simplă aici este dezactivarea serviciului Bonjour prin intermediul managerului de service.

Cu Avahi există încă o implementare gratuită ( LGPL ) și portabilă a mDNS / DNS-SD, care este acum standard în toate distribuțiile Linux.

Pentru ca rezoluția numelui pentru domeniul de nivel superior .local să fie procesată ca de obicei prin serverul DNS (de exemplu, BIND ) sub Linux, mDNS offeste /etc/host.confnecesară o intrare în fișier pentru implementările mai vechi .

Microsoft

Microsoft APIPA

APIPA de la Microsoft ar trebui să permită utilizatorilor casnici să opereze o rețea TCP / IP fără a fi nevoie să se ocupe de adresarea IP și de parametrii IP ai acesteia. Sistemul de operare încearcă mai întâi să ajungă la un server DHCP. Dacă o astfel de adresă nu poate fi accesată, o adresă aleatorie din zona 169.254.xx este atribuită automat.

Atribuirea automată a adresei IP APIPA a fost implementată în Windows de la Windows 98 . Cu toate acestea, nu respectă pe deplin IETF RFC . Microsoft numește această procedură Adresare IP privată automată sau APIPA pe scurt.

DNS-SD

  • Microsoft acceptă parțial DNS-SD în Windows 10 . Suportul a fost construit pas cu pas și a fost inițial utilizat numai în Windows pentru a permite unui client Windows 10 să găsească o imprimantă IPP în rețeaua locală. DNS-SD este acum utilizat și pentru a face publicitate și pentru a găsi dispozitive de afișare fără fir într-o rețea locală.
  • Pentru programatori, DNS-SD este disponibil prin intermediul API-ului Windows.Networking.ServiceDiscovery.Dnssd .
  • Un instrument pentru linia de comandă Windows 10 pentru DNS-SD este disponibil numai de la companii din afara, de exemplu ca parte a Bonjour pentru Windows a Apple.

mDNS

  • În Windows 10, descoperirea dispozitivului poate fi activată în modul dezvoltator. Aceasta permite suportul multicast în clientul DNS.
  • Un serviciu de răspuns mDNS de la Microsoft este disponibil în cod sursă pentru Windows IoT .
  • În WSL , mDNS este disponibil prin Avahi.

Mai multe protocoale

În funcție de versiunea și configurația Windows , sunt disponibile alte protocoale Microsoft proprietare, cum ar fi LLMNR , NBNS și SSDP . Microsoft nu recomandă utilizarea NBNS.

Norme și standarde

  • RFC 3927 - Configurare dinamică a adreselor IP-Link Link-Local
  • RFC 6762 - DNS multicast
  • RFC 6763 - Descoperire de servicii bazate pe DNS

Link-uri web

Dovezi individuale

  1. ↑ a b Rețea de configurare zero (zeroconf) . Task Force Inginerie Internet. Adus pe 29 aprilie 2012.
  2. ↑ RFC 6763 - Descoperire de servicii bazate pe DNS
  3. ↑ Pictograma tăvii de sistem de rețea Windows 7 afișează „acces la Internet” atunci când nu există. Adus la 13 octombrie 2019 (engleză americană).
  4. ↑ Baza de cunoștințe Microsoft: Gateway-ul implicit poate fi setat la 0.0.0.0 pe un sistem de operare Windows Vista sau ulterior care rulează serviciul Apple Bonjour
  5. ↑ Asistență | Probleme de rezolvare a numelor cu domenii „.local”. Adus la 14 aprilie 2017 .
  6. ↑ APIPA - Computer Lexicon - termeni tehnici clar explicați | PC, glosar EDP. Adus pe 12 iunie 2020 .
  7. ↑ APIPA. (Nu mai este disponibil online.) Arhivat din original la 20 noiembrie 2010 ; accesat la 25 octombrie 2010 (engleză).
  8. ↑ Adresare TCP / IP automată fără server DHCP. Adus la 25 octombrie 2010 .
  9. ↑ Spațiul de nume Windows.Networking.ServiceDiscovery.Dnssd. Accesat la 31 august 2020 .
  10. ↑ Mai multe funcții în modul dezvoltator. Accesat la 31 august 2020 .
  11. ↑ Noțiuni introductive despre eșantionul sursei serviciului de răspuns mDNS. Accesat la 31 august 2020 .