Shorewall-soner for dei to OpenVPN-pakkestiane
Skil den krypterte OpenVPN-transporten frå den dekrypterte klienttrafikken, gje tunnelen si eiga sone og tillat berre den eine tenesta klienten treng.
To pakkestraumar kryssar ein Shorewall-gateway som terminerer OpenVPN, og berre éin av dei er kryptert. Den første er transporten til klienten til VPN-lyttaren på grensesnittet som vender mot internett. Den andre er den dekrypterte førespurnaden som forlèt tunnelgrensesnittet til ein kontorserver eller ei teneste på gatewayen. Kartlegg begge før du redigerer policyen, fordi ein regel som tilfredsstiller den første ikkje gjer noko for den andre.
Teikn dei to straumane før du redigerer policyen
Skriv straumane som rader med kjelde, mål, protokoll og port. På den ytre stien er kjelda den offentlege adressa til klienten og målet lyttporten til gatewayen; Shorewall handsamar det som trafikk frå internett til brannmuren. På den indre stien er kjelda tunneladresseområdet og målet den godkjende tenesta. Dei to radene har ulike eigarar sjølv når éin administrator vedlikeheld begge.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Legg berre til ei rad viss førespurnaden endar på gatewayen sjølv, til dømes tilgang til resolvaren eller administrasjonen. Ei teneste på verten følgjer inngangspolicyen til verten, ikkje den videresende stien. Å blande dei to er korleis ein smal tunnelregel til slutt eksponerer eit administrasjonsgrensesnitt.
Tildel tunnelsona og omfanget til grensesnittet
Road-warrior-sona blir deklarert i /etc/shorewall/zones, tunnelgrensesnittet blir knytt i /etc/shorewall/interfaces, og den ytre sambindinga blir skildra i /etc/shorewall/tunnels. Tilpass deg syntaksen til den installerte utgåva, fordi kolonnerekkjefølgje og opsjonsnamn har endra seg mellom hovudversjonar. Eksempelporten i rettleiinga er ikkje grunn til å tillate ein annan port enn den daemonen faktisk lyttar på. TCP og UDP er ikkje utskiftbare berre fordi tala stemmer.
Rettleiinga grupperer grensesnitt med tun+. På ein vert med meir enn éin tunnel kan det jokerteiknet plassere ein annan VPN med eit anna tillitsnivå i same sone. Gå gjennom omfanget mot grensesnitta som faktisk finst, og hald namngjevinga under livssyklusen til tilkoplingshandsamaren i staden for å redigere grensesnittnamn for hand.
Den historiske rettleiinga inneheld mykje eldre OpenVPN-konfigurasjonseksempel, og kryptoråda bør ikkje kopierast til ein gjeldande utrulling. Lån i staden sone- og straummodellen. Ta det kryptografiske grunnlaget frå den vedlikehaldne OpenVPN-policyen til gatewayen.
Tillat berre stien du klassifiserte
Ein brei aksept frå VPN-sona til LAN er eit startdiagram, ikkje ein ferdig policy. Skriv den tillatne klientkjelda, den faktiske tenesteadressa, protokollen og porten. Les deretter reglane over han og standardverdien til sona, fordi eit smalt tillegg ikkje opphevar ei brei løyve som allereie passar. Trafikk til gatewayverten er eit eige tilhøve til trafikk som blir vidaresend gjennom han.
Trafikk mellom klientar treng si eiga avgjerd. OpenVPN sin client-to-client og Shorewall sin routeback påverkar begge om klientar kan nå kvarandre, og ingen av dei bør aktiverast berre for å få éin LAN-applikasjon til å verke. Avgjer kvar isolasjonen blir handheva før du testar han.
Hald returvegen i same plan. Tenesta eller rutaren hennar må vite korleis trafikk blir returnert til tunnelområdet, eller designet må omsetje kjelda medvite og innanfor det tiltenkte omfanget.
Valider, og prov deretter begge stiane
Valider konfigurasjonen før du startar noko på nytt, og hald ein uavhengig administrativ sesjon open i tilfelle den nye policyen er feil.
shorewall checkEtter ein rein sjekk brukar du konfigurasjonen og les tilbake kva Shorewall lasta. Desse lesingane skildrar den køyrande policyen snarare enn kva ei fil ser ut til å seie.
shorewall show zones
ip route get 192.168.10.20Test éin ny tillaten førespurnad og éin medvite avvist førespurnad frå same klient. Eit vellukka OpenVPN-handtrykk provar berre den ytre utvekslinga; den tillatne tenesta og den avviste ressursen provar den indre policyen du meinte. Kople deretter klienten til på nytt og gjer det om att, fordi namnet og adressa til tunnelgrensesnittet kan endre seg mellom sesjonar. Viss resultatet er annleis, rettar du soneomfanget i staden for å utvide regelen.