Miks OpenVPN-i kliendi blokeerimisreegel kunagi FORWARD-i ei jõua

Kaks klienti samal OpenVPN-serveril võivad üksteiseni jõuda ka siis, kui lisasid nende poolile DROP-reegli. Reegel asub FORWARD-ahelas, liiklus voolab selgelt, ja selle reegli loendur jääb nulli. Loomulik järeldus on, et tulemüür on katki. Sagedamini ei ole pakett ahelasse üldse sisenenud.

On kaks teed, mida partneri pakett võib OpenVPN-serverist läbida, ja need määrab konfiguratsioon, mitte tulemüür. Teadmine, millist teed kasutatakse, ütleb, kas hosti reegel on üldse õiges kohas.

Kaks teed, mida partneri pakett võib läbida

Kui sisemise edastamise valik on välja lülitatud, saabub kliendi A pakett tunneliliidesele sihtkohaga kliendi B määratud aadressi sees. Serveri marsruutimistabel saadab selle sama tunneliliidese kaudu tagasi, sest serverile kuulub marsruut B aadressini. See on hosti läbiv sisse-ja-välja voog, ja IPv4 edastustee hindab seda.

Kui sisemise edastamise valik on sisse lülitatud, sobitab serveriprotsess paketi ühendatud kliendiga ja kirjutab selle otse sellele kliendile tagasi. Paketti töödeldakse deemonis ega sisene kunagi uuesti tunneliseadmesse, seega jäetakse hosti edastustee täielikult vahele. OpenVPN 2.6 käsiraamat kirjeldab seda valikut sisemise kliendilt-kliendile edastamisena, ja just seepärast ei näe hosti tulemüürireegel seda.

Kolmas variant eksisteerib paigaldustes, mis viivad andmekanali kernelimoodulisse. Edastusotsus ja krüptimine lahkuvad kasutajaruumist, ja see, kas netfilter voogu näeb, sõltub sellest, kuidas üleandmise tee on ehitatud. Ära kunagi eelda, et vana reeglistik käitub üleandmisega serveris samamoodi nagu kasutajaruumi omas. Kinnita režiim töötavast konfiguratsioonist, mitte paketi versioonist.

Kui loendur ei liigu kunagi

Null-loendur tähendab, et pakett ei vastanud sellele reeglile selles punktis, ja põhjusi on mitu. Esimene on ülal kirjeldatud möödaminek: liiklus ei jõudnudki ahelani. Teine on lahknevus liideses, suunas, allikas või sihtkohas, mis on tavaline siis, kui pool nummerdati ümber ja reegel nimetab endiselt vana prefiksit.

Kolmas on asukoht. Ahelas varasem reegel võib voo vastu võtta enne, kui sinu DROP-i hinnatakse, ja hilisem reegel võib olla see, mis tegelikult tulemuse otsustab. Loe ahelat järjekorras nähtavate loenduritega, seejärel kontrolli, millise reegli loendur kasvab, kui katset korrad.

Tee üks kontrollitud vahetus kahe kliendi vahel, kelle tegelikud aadressid oled kinnitanud serveri enda olekust, mitte mälust meenuvast rendist. Kui asjakohane loendur ikka ei liigu, kahtlusta teed enne, kui sobitamise ümber kirjutad. Kui see liigub, aga ühendus õnnestub endiselt, siis tühistatakse drop hiljem ja probleem on järjestuses. See vastus otsustab, kas parandus on reegli muudatus või topoloogia muudatus, seega hangi see enne, kui midagi muudad.

Valida piir, mis suudab filtreerida

Kui poliitika peab elama hosti tulemüüris, pane liiklus sinna, kus tulemüür seda näeb. Sisemise edastamise väljalülitamine on toetatud viis panna partnerliiklus tunneliliidese ja edastustee kaudu liikuma, hinnaga, et iga partneri pakett läbib hosti virna.

Seejärel sobit täpselt voog. Liiklus saabub tunneliliidesele ja lahkub tunneliliideselt mõlemas suunas, seega reeglid, mis arvestavad ainult füüsilist liidest, ei sobi. Aadressipõhised reeglid vajavad praegust pooli ja peavad arvestama tagasisuunda nagu edasigi.

Paljusid paigaldusi teenib paremini kliendi või grupi tasandil filtreerimine, kus identiteet on teada ja poliitika järgib kasutajat, mitte aadressi, mis taasthendamisel muutub. See on teistsugune mehhanism kui hosti ahel, ja neid kahte ei tohiks ilma selge põhjuseta segada.

Ära vii vana topoloogia reeglistikku muutmata üle migratsiooni. Aadressipoolid, liidesenimed ja edastusrežiimid mõjutavad kõik seda, kas reegel sobib, ja kopeeritud reegel, mis varem töötas, on kõige eksitavam tõendiliik. Alusta voost, mida soovid lubada, ja kirjuta reegel, mis sellega sobib.

Isoleerimise testimine reegli usaldamise asemel

Testi keelatud juhtumit ja lubatud juhtumit samas käivituses. Alusta uue ühenduse ühest kliendist teise ja kinnita, et see ebaõnnestub, seejärel kinnita, et ühendus, mida peaks lubama, töötab endiselt. Kui testitakse ainult esimest, näeb kõike blokeeriv tulemüür välja nagu edu.

Korda pärast serveri konfiguratsiooni uuesti laadimist ja pärast kliendi taasühendumist, sest sisemine edastamine ja poolide määramine on käitusaegne olek. Kontrolli loendureid mõlemas suunas, sest reegel, mis sobib ühe suunaga ja mitte vastusega, tekitab osalise isoleerimise, mida on kiires testis raske märgata.

Isoleerimine on vaadeldud tulemus piiril, mis liiklust tegelikult kannab. DROP-reegel kuskil hostis ei ole tõend; ebaõnnestunud ühendus pluss selle põhjustanud reegli liikunud loendur on.