Geënkripteerde deurgang gee nie toegang tot die draer nie

Twee goedgekeurde gateways dra die verkeer van 'n netwerk met laer vertroue oor 'n beperkte vervoernetwerk. As die vrag geënkripteer word, bly dit onleesbaar vir gewone waarnemers op die deurgang, en dit is die deel wat mense eerste ontwerp en dan ophou oor dink. Wat enkripsie nie doen nie, is om te bepaal watter hulpbronne die laer-vertroue kant mag bereik. Die ontwerp het twee grense nodig: een rondom die gesprek wat vervoer word, en een rondom toegang tot die draer self.

Voer die stappe hieronder in volgorde uit, en hanteer 'n fout by enige stap as 'n ontwerpverandering eerder as 'n aanpassing van die konfigurasie.

Bepaal albei grense voordat jy aan 'n konfigurasie raak

Die eerste grens is die gesprek: watter pare gateways mag 'n tonnel opstel, en watter binneste verkeer mag daardeur. Die tweede is die draer: watter adresse en dienste die gashere met laer vertroue buite die tonnel mag bereik. Spanne bou gewoonlik die eerste en erf die tweede van watter roetering ook al bestaan het, en dit is hoe 'n beperkte ontwerp stilweg 'n wye een word. Daardie oorerwing is die gewone grondoorsaak wanneer 'n hersiening vind dat 'n gasheer met laer vertroue met iets praat wat niemand goedgekeur het nie.

Skryf albei neer as lyste van adresse, poorte en rigtings. As 'n lys nie geskryf kan word nie, is die grens nog nie bepaal nie.

Stap 1: beperk die buitenste tonnel

Laat op die koppelvlak na die draer net toe wat die tonnel nodig het: IKE op UDP 500 en 4500 tussen die twee gateway-adresse, en ESP waar NAT-traversering nie gebruik word nie. Weier alles anders wat op daardie koppelvlak aankom, insluitend bestuursprotokolle. Die ESP-spesifikasie dek die beskermingsdienste; dit sê niks oor watter van die draer se eie dienste die gateways mag gebruik nie. Druk dit uit as 'n eksplisiete toelaatlys, sodat 'n nuut gepubliseerde draerdiens nie by verstek bereikbaar word nie.

Dit is die reëlversameling wat die ontwerp 'n deurgangontwerp maak eerder as 'n peering-reëling.

Kontroleer dit van die laer-vertroue kant, nie van die gateway-konsole nie. 'n Gasheer daar behoort nie 'n draer-DNS-bediener te kan bereik nie, selfs voordat die tonnel op is.

Stap 2: besluit wat die verste gateway lewer

Aan die verre kant moet herwonne verkeer na iets spesifiek gaan. Bepaal watter binneste dienste toegelaat word, vanaf watter bronreekse, en of antwoorde simmetries verwag word. Hersien bestuustoegang afsonderlik, want dieselfde gateway stel dikwels 'n administratiewe koppelvlak bloot wat nooit deel van die deurgangplan was nie.

'n Diagram wat by suksesvolle dekripsie stop, het die besluit oorgeslaan wat die meeste saak maak.

Stap 3: hou eienaarskap per laag

Deurgangtoerusting ontvang en stuur steeds buitenste pakkette, so dit het pleisters en kapasiteitsbeplanning nodig. Tonnel-eindpunte verwerk die beskermde protokol en stel binneste verkeer aan hul stuurpad bloot, so hulle het hul eie reëls en hul eie monitering nodig. Finale toepassings verwerk die vrag, en 'n ondeursigtige vrag is nie bewyse dat 'n gedekripteerde aflaai onskadelik is nie.

Ken aan elke laag 'n eienaar toe. Die lae sonder 'n eienaar is diegene wat wegdrift.

Stap 4: verifieer, en gee dit dan aan die owerheid oor

Verifieer die buitenste pad met die tonnel op en die draer-reëls in plek. Probeer dan elke hulpbron wat die laer-vertroue kant nie behoort te bereik nie, en bevestig dat die mislukking 'n weiering is eerder as 'n tydsverloop wat 'n roete verberg. Kontroleer ook beskikbaarheid en hulpbronlimiete, want 'n geënkripteerde skakel kan steeds versadig word.

Vir gereguleerde of geklassifiseerde omgewings, neem die ontwerp na die verantwoordelike veiligheidsowerheid en gebruik sy goedgekeurde skeidingsargitektuur. 'n VPN-konfigurasie en 'n konseptuele verduideliking vestig nie akkreditasie nie. Daardie stap is nie papierwerk nie; dit bepaal of die ontwerp hoegenaamd mag bestaan.