Un angajat aflat în deplasare și o sucursală au nevoie de tuneluri diferite, iar alegerea greșită produce o proiectare care funcționează în laborator și eșuează în prima zi de luni. Accesul la distanță leagă un dispozitiv de o poartă. Site-to-site leagă două porți care reprezintă rețele. Lista de verificare de mai jos stabilește care dintre ele descrie de fapt cerința.

Cine formează numărul și ce se află în spatele celui care îl formează

La accesul la distanță, software-ul de pe laptop sau telefon stabilește tunelul, iar poarta autentifică un utilizator, un dispozitiv sau ambele înainte de a atribui o adresă și rute. La site-to-site, routerele, firewall-urile sau porțile cloud stabilesc conexiunea, iar dispozitivele din spatele lor folosesc rutarea obișnuită în loc să ruleze un client. Această diferență decide cine deține disponibilitatea tunelului: dispozitivul unui angajat în primul caz, un echipament administrat în al doilea. Ea decide și dacă autentificarea descrie o persoană sau o rețea.

Opriți-vă aici dacă cerința este ca fiecare mașină dintr-un birou să ajungă în alt birou fără configurare pentru fiecare dispozitiv. Aceasta este site-to-site, iar o grămadă de autentificări de acces la distanță este un substitut slab.

Adresarea și calea de întoarcere

Planificați intervale locale și la distanță distincte. Două locații pot folosi aceeași subrețea privată, iar proiectarea are atunci nevoie de traducere sau renumerotare înainte ca rutarea să fie neechivocă. Un router de acasă care folosește același interval ca sediul central creează aceeași problemă pentru un lucrător la distanță. Suprapunerea este destul de frecventă încât verificarea ei face parte din prima conversație.

Calea de întoarcere contează la fel de mult ca cea de ieșire. Un server poate primi o cerere și totuși să nu aibă rută înapoi către rețeaua clientului.

Documentați ce router cunoaște prefixul de la distanță, mai ales cu rețele cloud și mai multe porți. O pictogramă verde de tunel nu poate răspunde dacă o destinație are o cale de întoarcere funcțională, iar un ping într-o singură direcție nici atât. La accesul la distanță poarta deține de obicei ruta grupului; la site-to-site, fiecare router intermediar care transportă prefixul trebuie să fie de acord. Traducerea poate ascunde o rută lipsă până când se strică o aplicație care încorporează adrese.

Ieșirea în internet este o decizie separată

Accesibilitatea privată nu cere ca tunelul să transporte navigarea publică. Dacă traficul web obișnuit iese prin poartă este o a doua decizie, luată pentru fiecare proiectare și înregistrată în profilul clientului sau în configurația locației.

Tunelul complet și tunelul divizat sunt răspunsuri la acea întrebare, nu la întrebarea acces la distanță versus site-to-site. Numele interne au nevoie de DNS adecvat în ambele proiectări, deoarece un resolver public nu are răspuns pentru un nume de gazdă de birou privat. Trimiterea unui resolver și trimiterea unei rute implicite sunt setări înrudite, iar schimbarea uneia fără cealaltă produce defecțiuni care arată ca probleme DNS.

Folosiți topologia pentru a restrânge defectul

Un laptop care se deplasează pierde accesul la client, la propriul cont sau la rețeaua locală. O sucursală întreagă pierde accesul pe căile și porțile partajate.

Verificați mai întâi stabilirea tunelului, apoi rutele, apoi traficul permis, apoi rezolvarea numelor, apoi autentificarea în aplicație, și opriți-vă la primul pas care eșuează.ip route get 10.60.8.15 răspunde la întrebarea de rutare înainte să citiți un singur jurnal de aplicație. Setările de criptare nu repară o eroare de permisiune la un fișier partajat, iar un ping funcțional nu dovedește că o aplicație este autorizată. Păstrarea ordinii fixe împiedică modificările aleatorii de configurație care transformă un defect în trei.

În final, păstrați definițiile drepte când citiți material de la furnizori: un server comercial de ieșire în internet este un serviciu diferit de poarta privată a unei companii și nu acordă niciun acces la rețeaua acelei companii.

Articole similare