VPN-kliëntverkeer en vuurmuurtoestand: buitenste versus binneste vloei

Die VPN-handskud voltooi, die kliënt kry 'n adres, en 'n diens agter die poort weier steeds die verbinding. Die vuurmuur doen dikwels presies wat aan hom gesê is. Hy het die buitenste tonnelvloei toegelaat, wat 'n ander pakket is as die gedekapsuleerde programverbinding. Twee besluite volg: watter vloei jy toelaat, en of die grens hoegenaamd toestand volg.

Totdat jy dit skei, is elke reëlverandering 'n raaiskoot.

Die vuurmuur sien twee verskillende pakkette

Voor dekapsulering sien die vuurmuur verkeer wat na die VPN-eindpunt gerig is: 'n buitenste UDP-vloei na die luisteraar. Na dekapsulering dra 'n deurgestuurde pakket die kliënt se binneste adres en die diensbestemming.

'n Toelating vir die buitenste vloei magtig nie die deurgestuurde TCP-verbinding nie. Hulle kan in verskillende kettings, teen verskillende koppelvlakke en met verskillende adresse ná vertaling geëvalueer word.

Vergelyk opnames vanaf gelykwaardige posisies aan beide kante. 'n Opname by die tonnelrand en 'n opname by die bediener wys verskillende tuple vir dieselfde sessie.

Besluit een: laat die tonnel of die diens toe

As die kliënt net die VPN-eindpunt self nodig het, mag die buitenste toelating genoeg wees. As hy 'n diens anderkant die poort nodig het, het jy 'n deurstuurtoelating vir daardie bestemming en poort nodig. 'n Tonnelreël wat ook die diens toelaat, is 'n ontwerpkeuse wat jy behoort te benoem, nie 'n ongeluk nie.

Hou die kliëntreeks en die diensomvang smal. 'n Toelating van die tonnelsubnet na die hele LAN is 'n besluit om elke gasheer te vertrou, nie 'n kortpad vir een toepassing nie.

Skryf albei reëls afsonderlik neer. Die tonnelreël en die diensreël faal op verskillende maniere en word met verskillende bewyse ontfout. Wanneer een faal, weet jy watter laag eerste ondersoek moet word.

Besluit twee: met of sonder toestand by elke grens

'n Reël vir gevestigde vloei kan antwoorde vir 'n toegelate uitruiling toelaat, maar sy gedrag hang van die produk af. 'n Wolkgroep is gewoonlik toestandbehoudend; 'n subnet-ACL is dikwels toestandloos en vereis eksplisiete hantering in beide rigtings. Moenie aanvaar dat elke grens in die pad toestand op dieselfde manier hanteer nie. Lys elke grens en merk dit toestandbehoudend of toestandloos voordat jy die reëls ontwerp.

As 'n reël verander, kan bestaande dopgehoude vloei aanhou werk terwyl nuwes faal, of omgekeerd. Daardie verskil is 'n nuttige leidraad, nie 'n rede om alle verbindingstoestand op 'n lewendige poort te spoel nie.

Toets met 'n vars beheerde versoek en inspekteer die betrokke tellers. 'n Skoon toets is beter as 'n ontwrigtende herstelling. Noteer die tellernaam in die veranderingsrekord sodat die volgende toets dieselfde bewyse gebruik.

Verifieer die terugpad onder dieselfde beleid

Stuur 'n nuwe versoek van die kliënt na die diens en kyk dan na die vorentoe- en terugtellers by elke grens. Bevestig dat die antwoord die pad gebruik wat jy verwag, veral as vertaling betrokke is.

Hou die beoogde kliëntreeks en diensomvang smal, en verifieer die terugpad onder dieselfde reëlstel wat die versoek toegelaat het. 'n Reël wat net werk omdat 'n ou vloei nog oop is, is nie 'n werkende reël nie.