Waarom 'n OpenVPN-kliëntblokreël nooit die FORWARD-ketting tref nie

Twee kliënte op dieselfde OpenVPN-bediener kan mekaar bereik selfs al het jy 'n DROP-reël vir hulle poel bygevoeg. Die reël sit in die FORWARD-ketting, die verkeer vloei duidelik, en die teller vir daardie reël bly op nul. Die natuurlike gevolgtrekking is dat die brandmuur stukkend is. Dikwels het die pakkie glad nie eers die ketting binnegegaan nie.

Daar is twee paaie wat 'n eweknie-pakkie deur 'n OpenVPN-bediener kan volg, en hulle word deur die konfigurasie bepaal, nie deur die brandmuur nie. As jy weet watter pad in gebruik is, weet jy of 'n gasheerreël hoegenaamd op die regte plek sit.

Twee paaie wat 'n eweknie-pakkie kan volg

Met die interne deurvoer-opsie gedeaktiveer, kom 'n pakkie van kliënt A op die tonnelkoppelvlak aan met 'n bestemming binne kliënt B se toegewysde adres. Die bediener se roetetabel stuur dit terug deur dieselfde tonnelkoppelvlak, want die bediener besit die roete na B se adres. Dit is 'n in-en-uit vloei deur die gasheer, en die IPv4-deurvoerpad evalueer dit.

Met die interne deurvoer-opsie geaktiveer, pas die bedienerproses die pakkie by 'n gekoppelde kliënt en skryf dit self terug na daardie kliënt. Die pakkie word binne die daemon hanteer en betree nooit weer die tonneltoestel nie, so die gasheer se deurvoerpad word heeltemal oorgeslaan. Die OpenVPN 2.6-handleiding beskryf hierdie opsie as interne kliënt-tot-kliënt-deurvoer, en dit is presies waarom 'n gasheer-brandmuurreël dit nie kan sien nie.

Daar bestaan 'n derde variant in ontplooiings wat die datakanaal na 'n kernmodule aflaai. Die deurvoerbeslissing en die enkripsie beweeg uit die gebruikersruimte, en of netfilter die vloei sien, hang af van hoe die aflaapad gebou is. Moet nooit aanneem dat 'n ou reëlstel op 'n afgelaaide bediener dieselfde gedra as op een in die gebruikersruimte nie. Bevestig die modus uit die lopende konfigurasie, nie uit die pakketweergawe nie.

Wanneer die teller nooit beweeg nie

'n Nul-teller beteken die pakkie het daardie reël op daardie punt nie getref nie, en daar is verskeie redes. Die eerste is die ompad hierbo: die verkeer het nooit die ketting bereik nie. Die tweede is 'n wanpassing in koppelvlak, rigting, bron of bestemming, wat algemeen is wanneer die poel hernommer is en die reël nog die ou voorvoegsel noem.

Die derde is posisie. 'n Reël vroeër in die ketting kan die vloei aanvaar voordat jou DROP geëvalueer word, en 'n reël later kan die een wees wat die uitkoms werklik bepaal. Lees die ketting in volgorde met die tellers sigbaar, en kyk dan watter reël se telling toeneem wanneer jy die toets herhaal.

Voer een beheerde uitruiling uit tussen twee kliënte wie se werklike adresse jy uit die bediener se eie toestand bevestig het, nie uit 'n huurkontrak wat jy onthou nie. As die betrokke teller steeds nie beweeg nie, vermoed die pad voordat jy die passing herskryf. As dit beweeg maar die verbinding slaag steeds, word die drop later oorheers en die ordening is die probleem. Daardie antwoord bepaal of die herstel 'n reëlverandering of 'n topologieverandering is, so kry dit voordat jy enigiets wysig.

'n Grens kies wat kan filter

As die beleid in die gasheer se brandmuur moet woon, sit die verkeer waar die brandmuur dit kan sien. Om interne deurvoer te deaktiveer is die ondersteunde manier om eweknie-verkeer deur die tonnelkoppelvlak en die deurvoerpad te laat gaan, ten koste daarvan dat elke eweknie-pakkie deur die gasheer se stapel gestuur word.

Pas dan die vloei presies. Verkeer kom op die tonnelkoppelvlak aan en verlaat dit op die tonnelkoppelvlak, in beide rigtings, so reëls wat net die fisiese koppelvlak in ag neem, sal nie pas nie. Adresgebaseerde reëls het die huidige poel nodig, en hulle moet die terugrigting sowel as die heenrigting in ag neem.

Baie ontplooiings vaar beter daarmee om op kliënt- of groepvlak te filter, waar die identiteit bekend is en die beleid die gebruiker volg eerder as 'n adres wat by herverbinding verander. Dit is 'n ander meganisme as 'n gasheerketting, en die twee moet nie sonder 'n duidelike rede vermeng word nie.

Moet nie 'n ou topologie se reëlstel onveranderd deur 'n migrasie dra nie. Adrespoele, koppelvlakname en deurvoermodusse beïnvloed almal of 'n reël pas, en 'n gekopieerde reël wat vroeër gewerk het, is die mees misleidende soort bewys. Begin by die vloei wat jy wil toelaat en skryf die reël wat daarby pas.

Isolasie toets in plaas daarvan om 'n reël te vertrou

Toets die verbode geval en die toegelate geval in dieselfde lopie. Begin 'n nuwe verbinding van een kliënt na die ander en bevestig dat dit misluk, bevestig dan dat 'n verbinding wat toegelaat moet word, steeds werk. As net die eerste getoets word, lyk 'n brandmuur wat alles blokkeer soos 'n sukses.

Herhaal ná die herlaai van die bedienerkonfigurasie en nadat 'n kliënt weer gekoppel het, want interne deurvoer en poeltoewysings is looptydtoestand. Kontroleer tellers in beide rigtings, want 'n reël wat een rigting pas en nie die antwoord nie, lewer gedeeltelike isolasie wat in 'n vinnige toets moeilik op te merk is.

Isolasie is die waargenome resultaat by die grens wat die vloei werklik dra. 'n DROP-reël êrens in die gasheer is nie bewys nie; 'n mislukte verbinding plus 'n verskuiwende teller op die reël wat dit veroorsaak het, is dit.