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

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

Postoje dva puta kojima paket partnera može proći kroz OpenVPN poslužitelj, a određuje ih konfiguracija, ne vatrozid. Znati koji se put koristi govori vam je li pravilo hosta 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. Poslužiteljeva tablica usmjeravanja šalje ga natrag kroz isto tunelsko sučelje, jer poslužitelj posjeduje rutu do B-ove adrese. To je tok unutra i van kroz host, a prosljeđivački put IPv4 ga procjenjuje.

Kada je opcija internog prosljeđivanja uključena, poslužiteljev 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 hosta potpuno preskače. Priručnik za OpenVPN 2.6 opisuje ovu opciju kao interno prosljeđivanje klijent-na-klijent, i upravo zato pravilo vatrozida hosta 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 vidi li netfilter tok ovisi o tome kako je izgrađen put prebacivanja. Nikada ne pretpostavljajte da se stari skup pravila ponaša na poslužitelju s prebacivanjem isto kao na onom u korisničkom prostoru. Potvrdite način iz konfiguracije koja radi, a ne iz verzije paketa.

Kada se brojač nikada ne pomakne

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: promet 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 poslužitelja, a ne iz zakupa kojeg se sjećate. Ako se odgovarajući brojač još ne pomiče, sumnjajte na put prije nego što prepišete podudaranje. Ako se pomiče ali veza još uspijeva, odbacivanje se kasnije nadjačava i problem je u redoslijedu. Taj odgovor odlučuje je li popravak promjena pravila ili promjena topologije, pa ga pribavite prije bilo kakvog uređivanja.

Odabir granice koja može filtrirati

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

Zatim precizno uparite tok. Promet dolazi na tunelsko sučelje i odlazi s tunelskog sučelja, u oba smjera, pa se pravila koja razmatraju samo fizičko sučelje neće 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 hosta 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 načini prosljeđivanja svi utječu na to podudara li se pravilo, 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, vatrozid koji blokira sve izgleda kao uspjeh.

Ponovite nakon ponovnog učitavanja konfiguracije poslužitelja 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 hostu nije dokaz; neuspjela veza i pomaknut brojač na pravilu koje ju je prouzročilo jesu.