Hejmlaboratorio kun fendita tunelo: enkursigu tion, kion vi bezonas, ne ĉion
Plena tunelo estas kutimo el lerniloj, ne postulo de la laboratorio. Listigu la subretojn, nomojn kaj administrajn vojojn, kiujn vi vere bezonas, kaj poste enkursigu nur tiujn.
La konsilo, ke hejma laboratorio bezonas plenan tunelon, kutime venas el lernilo, kiu havis unu, ne el postulo. Fendita tunelo ne estas la kompromita versio de taŭga VPN; ĝi estas la versio, kies enkursigan tabelon vi povas klarigi. Laboratorio kun kvin servoj kaj administra fasado ne bezonas, ke ĉiu paketo, kiu forlasas la domon, trairu tunelon. Tio, kion ĝi bezonas, estas inventaro kaj vojo por ĉiu ero en tiu inventaro.
La mito: fendita tunelo estas kompromiso
La mito pluvivas ĉar plena tunelo estas pli facile agordebla unufoje kaj pli malfacile sencimigebla poste. Tiu interŝanĝo estas racia por tekokomputilo sur publika Wi-Fi kaj malĝusta por rako en la kelo.
Ĝi ankaŭ kaŝas duan supozon, nome ke la adresado de la laboratorio havas nenion komunan kun la reto, de kiu vi konektiĝas.
Inventaru la resursojn antaŭ la vojoj
Notu ĉiun subreton de la laboratorio, la servon, kiu loĝas tie, la nomon, per kiu vi solvas ĝin, kaj kiu rajtas atingi ĝin; la notoj pri plusendado por via pordego priskribas la revenan vojon, kontraŭ kiu vi planas. Aldonu la ujoajn gamojn kaj la LAN-gamojn, kiujn la fora kliento eble jam uzas, ĉar interkovro estas la malsukceso, kiun ĉi tiu inventaro malhelpas. Vojo, kiu kovras ĉiun privatan adreson, pli frue aŭ pli malfrue kolizios kun hejma reto. La inventaro estas ankaŭ la testplano, tial indas fari ĝin antaŭ ol agordi, ne poste.
Asignu al ĉiu resurso vojon: tra la tunelo, rekte, aŭ malpermesite. Resurso sen asignita vojo estas tiu, kiu poste generas la konfuzan subtenan demandon.
Kvin vicoj kaj kolumno da decidoj superas enkursigan tabelon, kiun neniu povas legi.
La pordego bezonas revenan vojon
Plusendado ĉe la pordego estas nur duono. La laboratorio bezonas vojon reen al la klienta provizo, aŭ subtenatan tradukan aranĝon, kiu ebligas la revenon. Se respondoj ne trovas la klienton, la tunelo ŝajnas konektita kaj ĉiu peto finiĝas per tempolimo; tio estas simptomo de enkursigado, ne fiasko de VPN. Kontrolu la revenan vojon kiel parton de la dezajno, ne kiel paŝon de sencimigado.
Klienta provizo, kiu interkovras la adresadon de la laboratorio mem, estas la alia duono de ĉi tiu problemo, kaj ĝi fiaskas ĝuste same.
Riparu la planon, ne la simptomojn, kiam la du gamoj kolizias.
Administraj kaj interretaj roloj estas apartaj
Decidu, ĉu nur trafiko de la laboratorio uzas la tunelon, ĉu ĝi ankaŭ iĝas interreta eliro. Ne aldonu implicitan vojon nur ĉar lernilo uzis unu, ĉar tiu decido ŝanĝas, kien iras ĉiu DNS-mendo kaj ĉiu ĝisdatiga kontrolo. Konservu eksteran vojon al la VPN-finpunkto mem, alie la tunelo provos porti siajn proprajn eksterajn ligon. Tenu administran aliron mallarĝa kaj atingebla per aprobita restaŭra metodo.
Privata DNS povas esti elektita por nomoj de la laboratorio, sen supozi ke ĉiu publika mendo bezonas la saman solvilon. Tio estas decido pri solvilo, ne decido pri vojo.
Ilia apartigo estas tio, kio igas la fiaskajn reĝimojn distingeblaj poste.
Testu de ekstere, ne de la LAN
Uzu eksteran rajtigitan ligon anstataŭ testo de la sama LAN, ĉar testo de la sama LAN povas tute kaŝi mankan revenan vojon. Kontrolu adreson de la laboratorio, ĝian privatan gastigantnomon, intencatan rektan celon kaj la postulatan fiaskan konduton. La fiaska kazo same gravas kiel la sukcesa kazo: resurso, kiu ne estu atingebla, devas vere ne esti atingebla. Notu ĉiujn kvar rezultojn antaŭ ol nomi la dezajnon finita.
Poste konservu la agordon de vojoj kaj DNS apud la inventaro, kun nomita posedanto. Kiam la laboratorio gajnos plian subreton, ĝisdatigu ambaŭ kaj retestu.
Ne klarigita vojo, kiu interkovras ekzistantan hejman reton, estas la implicita rezulto de pretersaltado de tiu paŝo.
La finita dezajno estas malgranda, dokumentita kaj enua, kion ĝuste laboratorio volas de sia reto. La interesa versio estas tiu, kiu rompiĝas dum vi estas for de hejmo.