Shorewall zone za dva puta paketa OpenVPN

Dva toka paketa prolaze kroz Shorewall pristupnik koji terminira OpenVPN, a samo je jedan od njih šifriran. Prvi je klijentov transport do VPN slušatelja na sučelju okrenutom internetu. Drugi je dešifrirani zahtjev koji napušta tunelsko sučelje prema uredskom poslužitelju ili usluzi na pristupniku. Mapirajte oba prije uređivanja pravila, jer pravilo koje zadovoljava prvi ne čini ništa za drugi.

Nacrtajte dva toka prije uređivanja pravila

Zapišite tokove kao retke s izvorom, odredištem, protokolom i portom. Na vanjskom putu izvor je klijentova javna adresa, a odredište je port slušatelja na pristupniku; Shorewall to tretira kao promet s interneta prema vatrozidu. Na unutarnjem putu izvor je raspon adresa tunela, a odredište odobrena usluga. Dva retka imaju različite vlasnike čak i kad ih održava jedan administrator.

Dodajte redak samo ako zahtjev završava na samom pristupniku, poput pristupa razrješivaču ili upravljanju. Usluga na hostu slijedi pravilo ulaznog prometa hosta, a ne proslijeđeni put. Miješanje dvaju jest način na koji usko tunelsko pravilo izloži administratorsko sučelje.

Dodijelite zonu tunela i opseg sučelja

Zona putujućeg korisnika deklarira se u /etc/shorewall/zones, tunelsko sučelje se pridružuje u /etc/shorewall/interfaces, a vanjska veza opisuje se u /etc/shorewall/tunnels. Uskladite se sa sintaksom instaliranog izdanja, jer se redoslijed stupaca i nazivi opcija mijenjaju između glavnih verzija. Primjer porta iz vodiča nije razlog da dopustite drugi port od onoga na kojem demon doista sluša. TCP i UDP nisu zamjenjivi samo zato što se brojevi podudaraju.

Vodič grupira sučelja pomoću tun+. Na hostu s više tunela taj zamjenski znak može smjestiti drugi VPN različite razine povjerenja u istu zonu. Pregledajte opseg prema sučeljima koja stvarno postoje i držite imenovanje unutar životnog ciklusa upravitelja veza umjesto ručnog uređivanja naziva sučelja.

Povijesni vodič sadrži mnogo starije primjere konfiguracije OpenVPN i njegove kriptografske savjete ne treba kopirati u trenutačnu implementaciju. Posudite umjesto toga model zone i tokova. Kriptografsku osnovu uzmite iz održavane OpenVPN politike na pristupniku.

Dopustite samo put koji ste klasificirali

Široko prihvaćanje iz VPN zone prema LAN-u početna je skica, a ne dovršena politika. Zapišite dopušteni izvor klijenta, stvarnu adresu usluge, protokol i port. Zatim pročitajte pravila iznad njega i zadano pravilo zone, jer uski dodatak ne poništava široku dozvolu koja se već podudara. Promet prema hostu pristupnika odvojen je odnos od prometa koji se preko njega prosljeđuje.

Promet između klijenata treba vlastitu odluku. OpenVPN-ov client-to-client i Shorewallov routeback oba utječu na to mogu li klijenti dosegnuti jedan drugoga, i nijedno se ne smije uključiti samo da bi jedna LAN aplikacija radila. Odlučite gdje se izolacija provodi prije nego što je testirate.

Držite povratni put u istom planu. Usluga ili njezin usmjerivač mora znati kako vratiti promet u raspon tunela, ili dizajn mora namjerno prevesti izvor i to unutar predviđenog opsega.

Provjerite, zatim dokažite oba puta

Provjerite konfiguraciju prije ponovnog pokretanja bilo čega i držite otvorenu neovisnu administratorsku sesiju u slučaju da je novo pravilo pogrešno.

shorewall check

Nakon čiste provjere primijenite konfiguraciju i pročitajte što je Shorewall učitao. Ta čitanja opisuju politiku koja radi, a ne ono što se čini da datoteka govori.

shorewall show zones
ip route get 192.168.10.20

Testirajte jedan novi dopušteni zahtjev i jedan namjerno odbijeni zahtjev s istog klijenta. Uspješno OpenVPN rukovanje dokazuje samo vanjsku razmjenu; dopuštena usluga i odbijeni resurs dokazuju unutarnju politiku koju ste namjeravali. Zatim ponovno povežite klijenta i ponovite, jer se naziv i adresa tunelskog sučelja mogu promijeniti između sesija. Ako se rezultat razlikuje, popravite opseg zone umjesto da proširite pravilo.