Tranziti i enkriptuar nuk jep akses te transportuesi

Dy porta të miratuara mbartin trafikun e një rrjeti me besim më të ulët përmes një rrjeti transporti të kufizuar. Enkriptimi i ngarkesës e mban atë të palexueshme për vëzhguesit e zakonshëm të tranzitit, dhe kjo është pjesa që njerëzit e projektojnë së pari dhe pastaj ndalojnë së menduari për të. Ajo që enkriptimi nuk bën është të përcaktojë se cilat burime mund të arrijë pala me besim më të ulët. Projekti ka nevojë për dy kufij: një rreth bisedës që mbartet dhe një rreth aksesit te vetë transportuesi.

Kryeni hapat më poshtë me radhë dhe trajtoni çdo dështim në çdo hap si ndryshim projekti, jo si rregullim konfigurimi.

Përcaktoni të dy kufijtë përpara se të prekni një konfigurim

Kufiri i parë është biseda: cilat palë portash mund të krijojnë një tunel dhe cili trafik i brendshëm lejohet të kalojë nëpër të. I dyti është transportuesi: cilat adresa dhe shërbime mund të arrijnë hostet me besim më të ulët jashtë tunelit. Ekipet zakonisht ndërtojnë të parin dhe trashëgojnë të dytin nga çdo rrugëzim që ekzistonte tashmë, dhe kështu një projekt i kufizuar bëhet në heshtje i gjerë. Ai trashëgim është shkaku rrënjësor i zakonshëm kur një rishikim gjen një host me besim më të ulët duke folur me diçka që askush nuk e miratoi.

Shkruajini të dyja si lista adresash, portash dhe drejtimesh. Nëse një listë nuk mund të shkruhet, kufiri ende nuk është përcaktuar.

Hapi 1: kufizoni tunelin e jashtëm

Në ndërfaqen që shikon nga transportuesi, lejoni vetëm atë që i nevojitet tunelit: IKE në UDP 500 dhe 4500 midis dy adresave të portës, dhe ESP aty ku nuk përdoret kalimi NAT. Refuzoni çdo gjë tjetër që mbërrin në atë ndërfaqe, duke përfshirë protokollet e menaxhimit. Specifikimi ESP mbulon shërbimet e mbrojtjes; nuk thotë asgjë për atë se cilat shërbime të vetë transportuesit mund të përdorin portat. Shpreheni këtë si një listë lejimesh të qartë, në mënyrë që një shërbim i transportuesit i publikuar së fundmi të mos bëhet i arritshëm si parazgjedhje.

Ky është grupi i rregullave që e bën projektin projekt tranziti dhe jo një marrëveshje peering.

Kontrollojeni nga pala me besim më të ulët, jo nga konsola e portës. Një host atje duhet të dështojë të arrijë një server DNS të transportuesit edhe përpara se tuneli të jetë ngritur.

Hapi 2: vendosni çfarë dorëzon porta e largët

Në skajin e largët, trafiku i rikuperuar duhet të shkojë në një vend të caktuar. Përcaktoni cilat shërbime të brendshme lejohen, nga cilat intervale burimi dhe nëse pritet që përgjigjet të jenë simetrike. Rishikoni aksesin e menaxhimit veçmas, sepse e njëjta portë shpesh ekspozon një ndërfaqe administrative që nuk ishte kurrë pjesë e planit të tranzitit.

Një diagram që ndalon te dekriptimi i suksesshëm ka anashkaluar vendimin që ka më shumë rëndësi.

Hapi 3: mbani pronësinë për çdo shtresë

Pajisja e tranzitit ende merr dhe përcjell paketa të jashtme, prandaj ka nevojë për arnime dhe planifikim kapaciteti. Pikat fundore të tunelit përpunojnë protokollin e mbrojtur dhe ekspozojnë trafikun e brendshëm në rrugën e tyre të përcjelljes, prandaj kanë nevojë për rregullat e tyre dhe monitorimin e tyre. Aplikacionet përfundimtare përpunojnë ngarkesën, dhe një ngarkesë e errët nuk është provë se një shkarkim i dekriptuar është i padëmshëm.

Caktoni një pronar për çdo shtresë. Shtresat pa pronar janë ato që shmangen.

Hapi 4: verifikoni, pastaj ia dorëzoni autoritetit

Verifikoni rrugën e jashtme me tunelin e ngritur dhe rregullat e transportuesit në vend. Pastaj provoni çdo burim që pala me besim më të ulët nuk duhet ta arrijë dhe konfirmoni se dështimi është refuzim dhe jo një afat që fsheh një rrugë. Kontrolloni gjithashtu disponueshmërinë dhe kufijtë e burimeve, sepse edhe një lidhje e enkriptuar mund të ngopet.

Për mjedise të rregulluara ose të klasifikuara, çojeni projektin te autoriteti përgjegjës i sigurisë dhe përdorni arkitekturën e tij të miratuar të ndarjes. Një konfigurim VPN dhe një shpjegim konceptual nuk vendosin akreditim. Ai hap nuk është letërsi; ai vendos nëse projektit i lejohet të ekzistojë fare.