Laborator de acasă și tunel divizat: rutează doar ce ai nevoie, nu tot
Un tunel complet este un obicei din tutoriale, nu o cerință a laboratorului. Listează subrețelele, numele și căile de administrare de care ai cu adevărat nevoie, apoi rutează doar pe acelea.
Sfatul că un laborator de acasă are nevoie de un tunel complet vine de obicei dintr-un tutorial care avea unul, nu dintr-o cerință. Tunelul divizat nu este versiunea compromisă a unui VPN corect; este versiunea al cărei tabel de rute îl poți explica. Un laborator cu cinci servicii și o interfață de administrare nu are nevoie ca fiecare pachet care pleacă din casă să treacă printr-un tunel. De ce are nevoie este un inventar și o rută pentru fiecare element din acel inventar.
Mitul: tunelul divizat este un compromis
Mitul supraviețuiește pentru că un tunel complet este mai ușor de configurat o dată și mai greu de depanat mai târziu. Schimbul acesta este rezonabil pentru un laptop pe Wi-Fi public și greșit pentru un rack din subsol.
Ascunde și o a doua presupunere: adresarea laboratorului nu are nimic în comun cu rețeaua de la care te conectezi.
Inventariază resursele înainte de rute
Notează fiecare subrețea a laboratorului, serviciul care locuiește acolo, numele prin care o rezolvi și cine are voie să ajungă la ea; notele de redirecționare pentru gateway-ul tău descriu calea de întoarcere față de care planifici. Adaugă intervalele de containere și intervalele LAN pe care clientul de la distanță le poate folosi deja, pentru că suprapunerea este eșecul pe care acest inventar îl previne. O rută care acoperă fiecare adresă privată va intra în conflict cu o rețea de acasă mai devreme sau mai târziu. Inventarul este și planul de testare, de aceea merită făcut înainte de configurare, nu după.
Atribuie fiecărei resurse o cale: prin tunel, direct sau refuzat. O resursă fără cale atribuită este cea care generează mai târziu întrebarea de suport confuză.
Cinci rânduri și o coloană de decizii bat un tabel de rute pe care nimeni nu îl poate citi.
Gateway-ul are nevoie de o cale de întoarcere
Redirecționarea pe gateway este doar jumătate. Laboratorul are nevoie de o rută înapoi la pool-ul de clienți, sau de o soluție de traducere acceptată care face întoarcerea posibilă. Dacă răspunsurile nu găsesc clientul, tunelul pare conectat și fiecare cerere expiră; acesta este un simptom de rutare, nu o defecțiune a VPN. Verifică calea de întoarcere ca parte a proiectării, nu ca pas de depanare.
Un pool de clienți care se suprapune peste adresarea proprie a laboratorului este cealaltă jumătate a acestei probleme și eșuează exact în același fel.
Remediază planul, nu simptomele, când cele două intervale se ciocnesc.
Rolurile de administrare și de internet sunt separate
Decide dacă doar traficul laboratorului folosește tunelul sau dacă acesta devine și o ieșire spre internet. Nu adăuga o rută implicită doar pentru că un tutorial a folosit una, pentru că acea decizie schimbă unde merge fiecare interogare DNS și fiecare verificare de actualizare. Păstrează o cale exterioară către punctul final VPN însuși, altfel tunelul va încerca să poarte propria conexiune exterioară. Menține accesul de administrare îngust și accesibil printr-o metodă de recuperare aprobată.
Se poate alege un DNS privat pentru numele laboratorului fără a presupune că fiecare interogare publică are nevoie de același resolver. Aceasta este o decizie a resolverului, nu o decizie a rutei.
Faptul că sunt separate este ceea ce face modurile de eșec distingibile mai târziu.
Testează din exterior, nu din LAN
Folosește o conexiune externă autorizată în locul unui test din același LAN, pentru că un test din același LAN poate ascunde complet o rută de întoarcere lipsă. Verifică o adresă a laboratorului, numele ei de gazdă privat, o destinație directă intenționată și comportamentul de eșec cerut. Cazul de eșec contează la fel de mult ca cel de succes: o resursă care nu ar trebui să fie accesibilă trebuie să fie într-adevăr inaccesibilă. Notează toate cele patru rezultate înainte de a declara proiectarea terminată.
Apoi salvează configurația de rute și DNS lângă inventar, cu un proprietar numit. Când laboratorul primește o altă subrețea, actualizează ambele și testează din nou.
O rută neexplicată care se suprapune peste o rețea de acasă existentă este rezultatul implicit al săririi acelui pas.
Proiectarea terminată este mică, documentată și plictisitoare, exact ce vrea un laborator de la rețeaua sa. Versiunea interesantă este cea care se strică în timp ce ești departe de casă.