Prečo pravidlo blokovania klienta OpenVPN nikdy nezasiahne FORWARD
Prevádzka medzi klientmi môže zostať vnútri procesu OpenVPN a nikdy neprejsť reťazec FORWARD hostiteľa, takže nulové počítadlo nič nedokazuje.
Dvaja klienti na tom istom serveri OpenVPN sa môžu navzájom dosiahnuť, aj keď ste pre ich pool pridali pravidlo DROP. Pravidlo sedí v reťazci FORWARD, prevádzka zjavne tečie a počítadlo tohto pravidla zostáva na nule. Prirodzený záver je, že firewall je pokazený. Častejšie paket do reťazca vôbec nevstúpil.
Existujú dve cesty, ktorými môže paket partnera prejsť cez server OpenVPN, a rozhoduje o nich konfigurácia, nie firewall. Znalosť toho, ktorá cesta sa používa, vám povie, či je pravidlo hostiteľa vôbec na správnom mieste.
Dve cesty, ktorými môže paket partnera prejsť
Keď je voľba vnútorného preposielania vypnutá, paket od klienta A dorazí na tunelové rozhranie s cieľom vnútri pridelenej adresy klienta B. Smerovacia tabuľka servera ho pošle späť cez to isté tunelové rozhranie, pretože trasa k adrese B patrí serveru. Je to tok dovnútra a von cez hostiteľa a vyhodnocuje ho cesta preposielania IPv4.
Keď je voľba vnútorného preposielania zapnutá, proces servera priradí paket pripojenému klientovi a zapíše ho späť priamo tomu klientovi. Paket sa spracuje vnútri démona a nikdy znova nevstúpi do tunelového zariadenia, takže cesta preposielania hostiteľa sa úplne preskočí. Manuál OpenVPN 2.6 opisuje túto voľbu ako vnútorné preposielanie klient-klient, a práve preto ho pravidlo firewallu hostiteľa nemôže vidieť.
Tretia varianta existuje v nasadeniach, ktoré presúvajú dátový kanál do modulu jadra. Rozhodnutie o preposielaní a šifrovanie sa presúvajú z používateľského priestoru a to, či netfilter tok vidí, závisí od toho, ako je cesta presunu postavená. Nikdy nepredpokladajte, že sa stará sada pravidiel správa na serveri s presunom rovnako ako na serveri v používateľskom priestore. Overte režim z bežiacej konfigurácie, nie z verzie balíka.
Keď sa počítadlo nikdy nepohne
Nulové počítadlo znamená, že paket v tom bode tomuto pravidlu nezodpovedal, a dôvodov je niekoľko. Prvý je obídenie vyššie: prevádzka sa do reťazca vôbec nedostala. Druhý je nesúlad v rozhraní, smere, zdroji alebo cieli, čo je bežné, keď bol pool prečíslovaný a pravidlo stále uvádza starý prefix.
Tretí je pozícia. Pravidlo skôr v reťazci môže tok prijať skôr, než sa vyhodnotí vaše DROP, a pravidlo neskôr môže byť to, ktoré výsledok skutočne rozhodne. Čítajte reťazec po poradí s viditeľnými počítadlami a potom skontrolujte, ktorému pravidlu pri opakovaní testu rastie počet.
Vykonajte jednu riadenú výmenu medzi dvoma klientmi, ktorých skutočné adresy ste potvrdili zo stavu samotného servera, nie z prenájmu, ktorý si pamätáte. Ak sa príslušné počítadlo stále nehýbe, podozrievajte cestu, kým prepíšete zhodu. Ak sa hýbe, ale spojenie stále uspeje, drop sa neskôr prepisuje a problém je v poradí. Táto odpoveď rozhoduje, či je oprava zmenou pravidla alebo zmenou topológie, tak si ju zaobstarajte pred akoukoľvek úpravou.
Voľba hranice, ktorá dokáže filtrovať
Ak politika musí žiť vo firewalle hostiteľa, umiestnite prevádzku tam, kde ju firewall vidí. Vypnutie vnútorného preposielania je podporovaný spôsob, ako prinútiť prevádzku partnerov prejsť tunelovým rozhraním a cestou preposielania, za cenu posielania každého paketu partnera cez zásobník hostiteľa.
Potom tok presne spárujte. Prevádzka prichádza na tunelové rozhranie a odchádza z tunelového rozhrania v oboch smeroch, takže pravidlá, ktoré berú do úvahy len fyzické rozhranie, nebudú zodpovedať. Pravidlá založené na adresách potrebujú aktuálny pool a musia počítať so spätným smerom rovnako ako s dopredným.
Mnohým nasadeniam lepšie poslúži filtrovanie na úrovni klienta alebo skupiny, kde je identita známa a politika sleduje používateľa, nie adresu, ktorá sa pri opätovnom pripojení mení. To je iný mechanizmus ako reťazec hostiteľa a oboje by sa nemalo miešať bez jasného dôvodu.
Neprenášajte sadu pravidiel starej topológie cez migráciu bez zmien. Adresné pooly, názvy rozhraní a režimy preposielania všetky ovplyvňujú, či pravidlo zodpovedá, a skopírované pravidlo, ktoré kedysi fungovalo, je najzavádzajúci druh dôkazu. Začnite tokom, ktorý chcete povoliť, a napíšte pravidlo, ktoré mu zodpovedá.
Testovanie izolácie namiesto dôvery v pravidlo
Otestujte zakázaný prípad a povolený prípad v jednom behu. Spustite nové spojenie z jedného klienta na druhého a potvrďte, že zlyhá, potom potvrďte, že spojenie, ktoré má byť povolené, stále funguje. Ak sa testuje len prvé, firewall, ktorý blokuje všetko, vyzerá ako úspech.
Zopakujte po opätovnom načítaní konfigurácie servera a po opätovnom pripojení klienta, pretože vnútorné preposielanie a prideľovanie poolov sú stav za behu. Kontrolujte počítadlá v oboch smeroch, keďže pravidlo, ktoré zodpovedá jednému smeru a nie odpovedi, vytvára čiastočnú izoláciu, ktorú je v rýchlom teste ťažké postrehnúť.
Izolácia je pozorovaný výsledok na hranici, ktorá tok skutočne nesie. Pravidlo DROP niekde v hostiteľovi nie je dôkaz; zlyhané spojenie plus pohnuté počítadlo na pravidle, ktoré ho spôsobilo, je.