Namų laboratorija ir padalintas tunelis: maršrutizuokite tai, ko reikia, o ne viską

Patarimas, kad namų laboratorijai reikia viso tunelio, paprastai ateina iš mokymo, kuriame jis buvo, o ne iš reikalavimo. Padalintas tunelis nėra tinkamo VPN kompromisinė versija; tai versija, kurios maršrutų lentelę galite paaiškinti. Laboratorijai su penkiomis paslaugomis ir valdymo sąsaja nereikia, kad kiekvienas paketas, paliekantis namus, eitų tuneliu. Jai reikia inventorizacijos ir maršruto kiekvienam tos inventorizacijos elementui.

Mitas: padalintas tunelis yra kompromisas

Mitas gyvuoja, nes visą tunelį lengviau vieną kartą sukonfigūruoti ir sunkiau vėliau derinti. Šis mainas pagrįstas nešiojamajam kompiuteriui viešame Wi-Fi ir neteisingas stelažui rūsyje.

Jis taip pat slepia antrą prielaidą: laboratorijos adresavimas neturi nieko bendra su tinklu, iš kurio jungiatės.

Inventorizuokite išteklius prieš maršrutus

Užrašykite kiekvieną laboratorijos potinklį, ten gyvenančią paslaugą, vardą, kuriuo ją išsprendžiate, ir kas turi teisę ją pasiekti; jūsų persiuntimo pastabos apie jūsų šliuzą aprašo grįžimo kelią, pagal kurį planuojate. Pridėkite konteinerių diapazonus ir LAN diapazonus, kuriuos nuotolinis klientas galbūt jau naudoja, nes persidengimas yra gedimas, kurį ši inventorizacija užkerta. Maršrutas, apimantis kiekvieną privatų adresą, anksčiau ar vėliau susidurs su namų tinklu. Inventorizacija taip pat yra testavimo planas, todėl verta ją atlikti prieš konfigūraciją, o ne po jos.

Priskirkite kiekvienam ištekliui kelią: tuneliu, tiesiogiai arba uždrausta. Išteklius be priskirto kelio yra tas, kuris vėliau sukelia painų pagalbos klausimą.

Penkios eilutės ir sprendimų stulpelis nugali maršrutų lentelę, kurios niekas negali perskaityti.

Šliuzui reikia grįžimo kelio

Persiuntimas šliuze yra tik pusė. Laboratorijai reikia maršruto atgal į klientų telkinį arba palaikomo vertimo sprendimo, kuris padarytų grįžimą įmanomą. Jei atsakymai neranda kliento, tunelis atrodo prijungtas, o kiekviena užklausa baigiasi laiko limitu; tai maršrutizavimo simptomas, o ne VPN gedimas. Tikrinkite grįžimo kelią kaip dizaino dalį, o ne trikčių šalinimo žingsnį.

Klientų telkinys, kuris persidengia su pačios laboratorijos adresavimu, yra kita šios problemos pusė, ir jis sugenda lygiai taip pat.

Taisykite planą, o ne simptomus, kai du diapazonai susiduria.

Valdymo ir interneto vaidmenys yra atskiri

Nuspręskite, ar tunelį naudoja tik laboratorijos srautas, ar jis tampa ir interneto išėjimu. Nepridėkite numatytojo maršruto vien todėl, kad mokymas jį naudojo, nes šis sprendimas pakeičia, kur eina kiekviena DNS užklausa ir kiekvienas atnaujinimų patikrinimas. Išsaugokite išorinį kelią iki paties VPN galinio taško, kitaip tunelis bandys nešti savo išorinį ryšį. Laikykite valdymo prieigą siaurą ir pasiekiamą patvirtintu atkūrimo metodu.

Laboratorijos vardams galima pasirinkti privatų DNS, nesant prielaidos, kad kiekvienai viešai užklausai reikia to paties sprendėjo. Tai sprendėjo sprendimas, o ne maršruto sprendimas.

Jų atskyrimas yra tai, kas vėliau leidžia atskirti gedimų būdus.

Bandykite iš išorės, o ne iš LAN

Naudokite išorinį leidžiamą ryšį, o ne testą iš to paties LAN, nes testas iš to paties LAN gali visiškai paslėpti trūkstamą grįžimo maršrutą. Patikrinkite laboratorijos adresą, jo privatų pagrindinio kompiuterio vardą, numatytą tiesioginę paskirties vietą ir reikiamą gedimo elgseną. Gedimo atvejis toks pat svarbus kaip ir sėkmės: išteklius, kurio neturėtų būti įmanoma pasiekti, turi būti tikrai nepasiekiamas. Užrašykite visus keturis rezultatus prieš skelbdami dizainą baigtu.

Tada išsaugokite maršrutų ir DNS konfigūraciją šalia inventorizacijos, nurodę savininką. Kai laboratorija gaus dar vieną potinklį, atnaujinkite abu ir išbandykite iš naujo.

Nepaaiškintas maršrutas, persidengiantis su esamu namų tinklu, yra numatytasis to žingsnio praleidimo rezultatas.

Baigtas dizainas yra mažas, dokumentuotas ir nuobodus, ir būtent to laboratorija nori iš savo tinklo. Įdomi versija yra ta, kuri lūžta, kai esate toli nuo namų.