Shorewall-zoner til de to OpenVPN-pakkeveje
Adskil den krypterede OpenVPN-transport fra dekrypteret klienttrafik, giv tunnelen sin egen zone, og tillad kun den ene tjeneste, klienten har brug for.
To pakkestrømme krydser en Shorewall-gateway, der terminerer OpenVPN, og kun den ene af dem er krypteret. Den første er klientens transport til VPN-lytteren på det internetvendte interface. Den anden er den dekrypterede anmodning, der forlader tunnel-interfacet til en kontorserver eller en tjeneste på gatewayen. Kortlæg dem begge, før du redigerer politikken, fordi en regel, der opfylder den første, intet gør for den anden.
Tegn de to strømme, før du redigerer politikken
Skriv strømmene som rækker med kilde, destination, protokol og port. På den ydre vej er kilden klientens offentlige adresse, og destinationen er gatewayens lytteport; Shorewall behandler det som trafik fra internettet til firewallen. På den indre vej er kilden tunneladresseområdet, og destinationen er den godkendte tjeneste. De to rækker har forskellige ejere, selv når én administrator vedligeholder 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 |
Tilføj kun en række, hvis anmodningen ender på gatewayen selv, såsom adgang til resolver eller administration. En tjeneste på værten følger værtens inputpolitik, ikke den videresendte vej. At blande de to er, hvordan en snæver tunnelregel ender med at eksponere en administrationsgrænseflade.
Tildel tunnelzonen og interfaceomfanget
Road-warrior-zonen erklæres i /etc/shorewall/zones, tunnel-interfacet knyttes i /etc/shorewall/interfaces, og den ydre forbindelse beskrives i /etc/shorewall/tunnels. Tilpas dig den installerede udgivelses syntaks, fordi kolonneorden og valgnavne har ændret sig mellem hovedversioner. Vejledningens eksempelport er ikke grund til at tillade en anden port end den, daemonen faktisk lytter på. TCP og UDP kan ikke udskiftes, blot fordi tallene passer.
Vejledningen grupperer interfaces med tun+. På en vært med mere end én tunnel kan det jokertegn placere et andet VPN med et andet tillidsniveau i den samme zone. Gennemgå omfanget mod de interfaces, der faktisk findes, og hold navngivningen under forbindelsesadministratorens livscyklus i stedet for at redigere interfacenavne i hånden.
Den historiske vejledning indeholder meget ældre OpenVPN-konfigurationseksempler, og dens kryptoråd bør ikke kopieres til en aktuel udrulning. Lån i stedet zone- og strømmodellen. Tag det kryptografiske grundlag fra gatewayens vedligeholdte OpenVPN-politik.
Tillad kun den vej, du har klassificeret
En bred accept fra VPN-zone til LAN er et startdiagram, ikke en færdig politik. Skriv den tilladte klientkilde, den faktiske tjenesteadresse, protokollen og porten. Læs derefter reglerne oven over og zonens standard, fordi en snæver tilføjelse ikke ophæver en bred tilladelse, der allerede matcher. Trafik til gatewayværten er et separat forhold fra trafik, der videresendes gennem den.
Klient-til-klient-trafik kræver sin egen beslutning. OpenVPNs client-to-client og Shorewalls routeback påvirker begge, om klienter kan nå hinanden, og ingen af dem bør aktiveres blot for at få én LAN-applikation til at virke. Beslut, hvor isoleringen håndhæves, før du tester den.
Hold svarvejen i samme plan. Tjenesten eller dens router skal vide, hvordan trafik returneres til tunnelområdet, eller designet skal oversætte kilden bevidst og inden for det tilsigtede omfang.
Validér, og bevis derefter begge veje
Validér konfigurationen, før du genstarter noget, og hold en uafhængig administrativ session åben i tilfælde af, at den nye politik er forkert.
shorewall checkEfter et rent tjek skal du anvende konfigurationen og læse tilbage, hvad Shorewall har indlæst. Disse læsninger beskriver den kørende politik snarere end det, en fil ser ud til at sige.
shorewall show zones
ip route get 192.168.10.20Test én ny tilladt anmodning og én bevidst afvist anmodning fra den samme klient. Et vellykket OpenVPN-håndtryk beviser kun den ydre udveksling; den tilladte tjeneste og den afviste ressource beviser den indre politik, du havde til hensigt. Genopret derefter klienten, og gentag, fordi tunnel-interfacets navn og adresse kan ændre sig mellem sessioner. Hvis resultatet er anderledes, skal du rette zoneomfanget i stedet for at udvide reglen.