Shorewall-soner for de to OpenVPN-pakkestiene
Skille den krypterte OpenVPN-transporten fra den dekrypterte klienttrafikken, gi tunnelen sin egen sone og tillat bare den ene tjenesten klienten trenger.
To pakkestrømmer krysser en Shorewall-gateway som terminerer OpenVPN, og bare én av dem er kryptert. Den første er klientens transport til VPN-lytteren på det internettvendte grensesnittet. Den andre er den dekrypterte forespørselen som forlater tunnelgrensesnittet til en kontorserver eller en tjeneste på gatewayen. Kartlegg begge før du redigerer policyen, fordi en regel som tilfredsstiller den første ikke gjør noe for den andre.
Tegn de to strømmene før du redigerer policyen
Skriv strømmene som rader med kilde, destinasjon, protokoll og port. På den ytre stien er kilden klientens offentlige adresse og destinasjonen gatewayens lyttport; Shorewall behandler det som trafikk fra internett til brannmuren. På den indre stien er kilden tunneladresseområdet og destinasjonen den godkjente tjenesten. De to radene har forskjellige eiere selv når én administrator vedlikeholder 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 bare til en rad hvis forespørselen ender på gatewayen selv, for eksempel tilgang til resolver eller administrasjon. En tjeneste på verten følger vertens inngangspolicy, ikke den videresendte stien. Å blande de to er hvordan en smal tunnelregel ender med å eksponere et administrasjonsgrensesnitt.
Tildel tunnelsonen og grensesnittomfanget
Road-warrior-sonen deklareres i /etc/shorewall/zones, tunnelgrensesnittet knyttes i /etc/shorewall/interfaces, og den ytre forbindelsen beskrives i /etc/shorewall/tunnels. Tilpass deg syntaksen til den installerte utgivelsen, fordi kolonnerekkefølge og opsjonsnavn har endret seg mellom hovedversjoner. Veiledningens eksempelport er ikke grunn til å tillate en annen port enn den daemonen faktisk lytter på. TCP og UDP er ikke utskiftbare bare fordi tallene stemmer.
Veiledningen grupperer grensesnitt med tun+. På en vert med mer enn én tunnel kan det jokertegnet plassere en annen VPN med et annet tillitsnivå i samme sone. Gå gjennom omfanget mot grensesnittene som faktisk finnes, og hold navngivningen under livssyklusen til tilkoblingsbehandleren i stedet for å redigere grensesnittnavn for hånd.
Den historiske veiledningen inneholder mye eldre OpenVPN-konfigurasjonseksempler, og kryptorådene bør ikke kopieres til en gjeldende utrulling. Lån i stedet sone- og strømmodellen. Ta det kryptografiske grunnlaget fra gatewayens vedlikeholdte OpenVPN-policy.
Tillat bare stien du klassifiserte
En bred aksept fra VPN-sonen til LAN er et startdiagram, ikke en ferdig policy. Skriv den tillatte klientkilden, den faktiske tjenesteadressen, protokollen og porten. Les deretter reglene over den og sonens standardverdi, fordi et smalt tillegg ikke opphever en bred tillatelse som allerede passer. Trafikk til gatewayverten er et eget forhold til trafikk som videresendes gjennom den.
Trafikk mellom klienter trenger sin egen beslutning. OpenVPNs client-to-client og Shorewalls routeback påvirker begge om klienter kan nå hverandre, og ingen av dem bør aktiveres bare for å få én LAN-applikasjon til å virke. Bestem hvor isolasjonen håndheves før du tester den.
Hold returveien i samme plan. Tjenesten eller ruteren må vite hvordan trafikk returneres til tunnelområdet, eller designet må oversette kilden bevisst og innenfor det tiltenkte omfanget.
Valider, og bevis deretter begge stier
Valider konfigurasjonen før du starter noe på nytt, og hold en uavhengig administrativ sesjon åpen i tilfelle den nye policyen er feil.
shorewall checkEtter en ren sjekk, bruk konfigurasjonen og les tilbake hva Shorewall lastet. Disse lesingene beskriver den kjørende policyen snarere enn hva en fil ser ut til å si.
shorewall show zones
ip route get 192.168.10.20Test én ny tillatt forespørsel og én bevisst avvist forespørsel fra samme klient. Et vellykket OpenVPN-håndtrykk beviser bare den ytre utvekslingen; den tillatte tjenesten og den avviste ressursen beviser den indre policyen du mente. Koble deretter klienten til på nytt og gjenta, fordi tunnelgrensesnittets navn og adresse kan endre seg mellom sesjoner. Hvis resultatet er annerledes, rett sonenomfanget i stedet for å utvide regelen.