Zašto pravilo blokiranja OpenVPN klijenta nikada ne pogađa FORWARD

Dva klijenta na istom OpenVPN serveru mogu dosegnuti jedan drugog čak i nakon što ste dodali DROP pravilo za njihov pool. Pravilo stoji u FORWARD lancu, saobraćaj očito teče, a brojač tog pravila ostaje na nuli. Prirodan zaključak je da je firewall pokvaren. Češće paket nikada nije ni ušao u lanac.

Postoje dva puta kojima paket partnera može proći kroz OpenVPN server, a određuje ih konfiguracija, ne firewall. Znati koji se put koristi govori vam da li je pravilo domaćina uopće na pravom mjestu.

Dva puta kojima paket partnera može proći

Kada je opcija internog prosljeđivanja isključena, paket od klijenta A dolazi na tunelsko sučelje s odredištem unutar dodijeljene adrese klijenta B. Serverova tabela rutiranja šalje ga natrag kroz isto tunelsko sučelje, jer server posjeduje rutu do B-ove adrese. To je tok unutra i van kroz domaćina, a prosljeđivački put IPv4 ga procjenjuje.

Kada je opcija internog prosljeđivanja uključena, serverski proces uparuje paket s povezanim klijentom i zapisuje ga natrag samom tom klijentu. Paket se obrađuje unutar daemona i nikada ponovno ne ulazi u tunelski uređaj, pa se prosljeđivački put domaćina potpuno preskače. Priručnik za OpenVPN 2.6 opisuje ovu opciju kao interno prosljeđivanje klijent-na-klijent, i upravo zato pravilo firewall-a domaćina to ne može vidjeti.

Treća varijanta postoji u instalacijama koje podatkovni kanal prebacuju na kernel modul. Odluka o prosljeđivanju i enkripcija izlaze iz korisničkog prostora, a to da li netfilter vidi tok zavisi od toga kako je izgrađen put prebacivanja. Nikada ne pretpostavljajte da se stari skup pravila ponaša na serveru s prebacivanjem isto kao na onom u korisničkom prostoru. Potvrdite režim iz konfiguracije koja radi, a ne iz verzije paketa.

Kada se brojač nikada ne pomjeri

Nula na brojaču znači da paket nije odgovarao tom pravilu u toj točki, a razloga je nekoliko. Prvi je gore opisano zaobilaženje: saobraćaj nikada nije stigao do lanca. Drugi je neusklađenost u sučelju, smjeru, izvoru ili odredištu, što je uobičajeno kada je pool ponovno numeriran, a pravilo još navodi stari prefiks.

Treći je položaj. Pravilo ranije u lancu može prihvatiti tok prije nego što se vaš DROP procijeni, a pravilo kasnije može biti ono koje zapravo odlučuje o ishodu. Čitajte lanac redom s vidljivim brojačima, zatim provjerite čiji brojač raste kada ponovite test.

Izvedite jednu kontroliranu razmjenu između dva klijenta čije ste stvarne adrese potvrdili iz samog stanja servera, a ne iz zakupa kojeg se sjećate. Ako se odgovarajući brojač još ne pomjera, sumnjajte na put prije nego što prepišete podudaranje. Ako se pomjera ali veza još uspijeva, odbacivanje se kasnije nadjačava i problem je u redoslijedu. Taj odgovor odlučuje je li popravka promjena pravila ili promjena topologije, pa ga pribavite prije bilo kakvog uređivanja.

Odabir granice koja može filtrirati

Ako politika mora živjeti u firewall-u domaćina, smjestite saobraćaj tamo gdje ga firewall može vidjeti. Isključivanje internog prosljeđivanja je podržan način da saobraćaj partnera prolazi kroz tunelsko sučelje i prosljeđivački put, uz cijenu slanja svakog paketa partnera kroz stog domaćina.

Zatim precizno uparite tok. Saobraćaj dolazi na tunelsko sučelje i odlazi s tunelskog sučelja, u oba smjera, pa pravila koja razmatraju samo fizičko sučelje neće se upariti. Pravila zasnovana na adresama trebaju trenutni pool i moraju uzeti u obzir povratni smjer kao i prednji.

Mnogim instalacijama bolje služi filtriranje na razini klijenta ili grupe, gdje je identitet poznat i politika slijedi korisnika umjesto adrese koja se mijenja pri ponovnom spajanju. To je drugačiji mehanizam od lanca domaćina i njih dvoje ne treba miješati bez jasnog razloga.

Ne prenosite skup pravila stare topologije kroz migraciju nepromijenjen. Poolovi adresa, imena sučelja i režimi prosljeđivanja svi utječu na to da li se pravilo podudara, a kopirano pravilo koje je nekad radilo najzavodljivija je vrsta dokaza. Pođite od toka koji želite dopustiti i napišite pravilo koje mu odgovara.

Testiranje izolacije umjesto vjerovanja pravilu

Testirajte zabranjeni slučaj i dopušteni slučaj u istom izvršavanju. Pokrenite novu vezu s jednog klijenta na drugi i potvrdite da ne uspijeva, zatim potvrdite da veza koja bi trebala biti dopuštena još radi. Ako se testira samo prvo, firewall koji blokira sve izgleda kao uspjeh.

Ponovite nakon ponovnog učitavanja konfiguracije servera i nakon što se klijent ponovno poveže, jer su interno prosljeđivanje i dodjele poolova izvršno stanje. Provjerite brojače u oba smjera, jer pravilo koje odgovara jednom smjeru a ne odgovoru stvara djelomičnu izolaciju koju je u brzom testu teško primijetiti.

Izolacija je uočeni rezultat na granici koja stvarno nosi tok. DROP pravilo negdje u domaćinu nije dokaz; neuspjela veza i pomjeren brojač na pravilu koje ju je prouzročilo jesu.