Kodėl OpenVPN kliento blokavimo taisyklė niekada nepasiekia FORWARD

Du klientai tame pačiame OpenVPN serveryje gali pasiekti vienas kitą net po to, kai jų telkiniui pridėjote DROP taisyklę. Taisyklė yra FORWARD grandinėje, srautas akivaizdžiai teka, o tos taisyklės skaitiklis lieka nulis. Natūrali išvada – ugniasienė sugedusi. Dažniau paketas net neįėjo į grandinę.

Yra du keliai, kuriais gali eiti bendraamžio paketas per OpenVPN serverį, ir juos lemia konfigūracija, o ne ugniasienė. Žinojimas, kuris kelias naudojamas, pasako, ar prieglobos taisyklė apskritai yra tinkamoje vietoje.

Du keliai, kuriais gali eiti bendraamžio paketas

Kai vidinio persiuntimo parinktis išjungta, paketas iš kliento A atvyksta į tunelio sąsają su paskirties vieta kliento B priskirto adreso viduje. Serverio maršrutų lentelė išsiunčia jį atgal per tą pačią tunelio sąsają, nes maršrutas iki B adreso priklauso serveriui. Tai įėjimo ir išėjimo srautas per prieglobą, ir jį vertina IPv4 persiuntimo kelias.

Kai vidinio persiuntimo parinktis įjungta, serverio procesas suporuoja paketą su prisijungusiu klientu ir įrašo jį atgal tiesiai tam klientui. Paketas apdorojamas demono viduje ir niekada nepatenka atgal į tunelio įrenginį, todėl prieglobos persiuntimo kelias visiškai praleidžiamas. OpenVPN 2.6 vadove ši parinktis apibūdinama kaip vidinis persiuntimas iš kliento klientui, ir būtent todėl prieglobos ugniasienės taisyklė negali jo matyti.

Yra trečias variantas diegimuose, kurie duomenų kanalą perkelia į branduolio modulį. Persiuntimo sprendimas ir šifravimas palieka vartotojo erdvę, o ar netfilter mato srautą, priklauso nuo to, kaip sukurtas perkėlimo kelias. Niekada nemanote, kad sena taisyklių visuma perkeltame serveryje elgiasi taip pat kaip vartotojo erdvės serveryje. Patvirtinkite režimą iš veikiančios konfigūracijos, o ne iš paketo versijos.

Kai skaitiklis niekada nejuda

Nulinis skaitiklis reiškia, kad tame taške paketas neatitiko tos taisyklės, ir priežasčių yra kelios. Pirmoji – aukščiau aprašytas apėjimas: srautas niekada nepasiekė grandinės. Antroji – sąsajos, krypties, šaltinio ar paskirties neatitikimas, kuris įprastas, kai telkinys buvo pernumeruotas, o taisyklė dar nurodo seną prefiksą.

Trečioji – padėtis. Ankstesnė grandinės taisyklė gali priimti srautą prieš tai, kai įvertinama jūsų DROP, o vėlesnė taisyklė gali būti ta, kuri iš tikrųjų nulemia rezultatą. Skaitykite grandinę iš eilės su matomais skaitikliais, tada patikrinkite, kurios taisyklės skaičius padidėja kartojant bandymą.

Atlikite vieną kontroliuojamą pasikeitimą tarp dviejų klientų, kurių tikruosius adresus patvirtinote iš paties serverio būsenos, o ne iš įsimintos nuomos. Jei atitinkamas skaitiklis vis dar nejuda, įtarkite kelią prieš perrašydami atitikimą. Jei jis juda, bet ryšys vis tiek pavyksta, drop yra vėliau perrašomas, ir problema yra tvarka. Šis atsakymas nulemia, ar taisymas yra taisyklės pakeitimas, ar topologijos pakeitimas, todėl gaukite jį prieš ką nors redaguodami.

Pasirinkti ribą, kuri gali filtruoti

Jei politika turi gyventi prieglobos ugniasienėje, įdėkite srautą ten, kur ugniasienė jį mato. Vidinio persiuntimo išjungimas yra palaikomas būdas priversti bendraamžių srautą pereiti tunelio sąsają ir persiuntimo kelią, tačiau už tai kiekvienas bendraamžio paketas eina per prieglobos steką.

Tada tiksliai suporuokite srautą. Srautas ateina į tunelio sąsają ir išeina per tunelio sąsają abiem kryptimis, todėl taisyklės, kurios atsižvelgia tik į fizinę sąsają, nesuporuos. Adresais pagrįstoms taisyklėms reikia dabartinio telkinio, ir jos turi atsižvelgti į grįžimo kryptį taip pat kaip į pirmyn.

Daugeliui diegimų geriau tarnauja filtravimas kliento ar grupės lygiu, kur tapatybė žinoma ir politika seka naudotoją, o ne adresą, kuris keičiasi prisijungiant iš naujo. Tai kitas mechanizmas nei prieglobos grandinė, ir jų dviejų nederėtų maišyti be aiškios priežasties.

Neperkelkite senos topologijos taisyklių visumos per migraciją nepakeistos. Adresų telkiniai, sąsajų pavadinimai ir persiuntimo režimai visi lemia, ar taisyklė atitinka, o nukopijuota taisyklė, kuri anksčiau veikė, yra klaidinantis įrodymų tipas. Pradėkite nuo srauto, kurį norite leisti, ir parašykite jį atitinkančią taisyklę.

Tikrinti izoliaciją, o ne pasitikėti taisykle

Išbandykite draudžiamą atvejį ir leidžiamą atvejį tame pačiame paleidime. Pradėkite naują ryšį iš vieno kliento į kitą ir patvirtinkite, kad jis nepavyksta, tada patvirtinkite, kad ryšys, kuris turėtų būti leidžiamas, vis dar veikia. Jei tikrinamas tik pirmasis, viską blokuojanti ugniasienė atrodo kaip sėkmė.

Pakartokite po serverio konfigūracijos įkėlimo iš naujo ir po kliento prisijungimo iš naujo, nes vidinis persiuntimas ir telkinių priskyrimai yra vykdymo laiko būsena. Tikrinkite skaitiklius abiem kryptimis, nes taisyklė, kuri atitinka vieną kryptį, bet ne atsakymą, sukuria dalinę izoliaciją, kurią greitame bandyme sunku pastebėti.

Izoliacija yra stebimas rezultatas ties riba, kuri iš tikrųjų neša srautą. DROP taisyklė kažkur priegloboje nėra įrodymas; nepavykęs ryšys ir jį sukėlusios taisyklės pajudėjęs skaitiklis yra įrodymas.