Shorewall-zones voor de twee OpenVPN-pakketpaden
Scheid het versleutelde OpenVPN-transport van het ontsleutelde clientverkeer, geef de tunnel zijn eigen zone en sta alleen de ene dienst toe die de client nodig heeft.
Twee pakketstromen kruisen een Shorewall-gateway die OpenVPN termineert, en slechts één ervan is versleuteld. De eerste is het transport van de client naar de VPN-listener op de naar internet gerichte interface. De tweede is het ontsleutelde verzoek dat de tunnelinterface verlaat naar een kantoorserver of een dienst op de gateway. Breng beide in kaart voordat u het beleid bewerkt, want een regel die aan de eerste voldoet, doet niets voor de tweede.
Teken de twee stromen voordat u het beleid bewerkt
Schrijf de stromen als rijen met bron, bestemming, protocol en poort. Op het buitenste pad is de bron het openbare adres van de client en de bestemming de luisterpoort van de gateway; Shorewall behandelt dat als verkeer van internet naar de firewall. Op het binnenste pad is de bron het tunneladresbereik en de bestemming de goedgekeurde dienst. De twee rijen hebben verschillende eigenaren, zelfs wanneer één beheerder beide onderhoudt.
| 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 |
Voeg alleen een rij toe als het verzoek op de gateway zelf eindigt, zoals toegang tot de resolver of het beheer. Een dienst op de host volgt het host-inputbeleid, niet het doorgestuurde pad. Het mengen van beide is de manier waarop een smalle tunnelregel uiteindelijk een beheerinterface blootlegt.
Wijs de tunnelzone en de interfacescope toe
De road-warriorzone wordt gedeclareerd in /etc/shorewall/zones, de tunnelinterface wordt gekoppeld in /etc/shorewall/interfaces en de buitenste verbinding wordt beschreven in /etc/shorewall/tunnels. Pas u aan de syntaxis van de geïnstalleerde release aan, want kolomvolgorde en optienamen zijn tussen hoofdversies veranderd. De voorbeeldpoort uit de handleiding is geen reden om een andere poort toe te staan dan die waarop de daemon werkelijk luistert. TCP en UDP zijn niet uitwisselbaar alleen omdat de nummers overeenkomen.
De handleiding groepeert interfaces met tun+. Op een host met meer dan één tunnel kan dat jokerteken een tweede VPN met een ander vertrouwensniveau in dezelfde zone plaatsen. Controleer de scope tegen de interfaces die werkelijk bestaan, en houd de naamgeving onder de levenscyclus van de verbindingsbeheerder in plaats van interfacenamen met de hand te bewerken.
De historische handleiding bevat veel oudere OpenVPN-configuratievoorbeelden, en het cryptoadvies ervan moet niet in een huidige uitrol worden gekopieerd. Leen in plaats daarvan het zone- en stromenmodel. Neem de cryptografische basis uit het onderhouden OpenVPN-beleid van de gateway.
Sta alleen het pad toe dat u hebt geclassificeerd
Een brede acceptatie van de VPN-zone naar het LAN is een beginschema, geen afgerond beleid. Schrijf de toegestane clientbron, het werkelijke dienstadres, het protocol en de poort. Lees daarna de regels erboven en de standaardwaarde van de zone, want een smalle toevoeging heft een brede toestemming die al overeenkomt niet op. Verkeer naar de gatewayhost is een aparte relatie van verkeer dat erdoorheen wordt doorgestuurd.
Verkeer tussen clients vraagt een eigen beslissing. OpenVPN's client-to-client en Shorewalls routeback beïnvloeden beide of clients elkaar kunnen bereiken, en geen van beide mag worden ingeschakeld alleen om één LAN-applicatie te laten werken. Bepaal waar isolatie wordt afgedwongen voordat u het test.
Houd het antwoordpad in hetzelfde plan. De dienst of zijn router moet weten hoe verkeer naar het tunnelbereik terugkeert, of het ontwerp moet de bron bewust en binnen de beoogde scope vertalen.
Valideer en bewijs daarna beide paden
Valideer de configuratie voordat u iets herstart, en houd een onafhankelijke beheersessie open voor het geval het nieuwe beleid onjuist is.
shorewall checkNa een schone controle past u de configuratie toe en leest u terug wat Shorewall heeft geladen. Deze uitlezingen beschrijven het draaiende beleid en niet wat een bestand lijkt te zeggen.
shorewall show zones
ip route get 192.168.10.20Test één nieuw toegestaan verzoek en één bewust geweigerd verzoek vanaf dezelfde client. Een geslaagde OpenVPN-handshake bewijst alleen de buitenste uitwisseling; de toegestane dienst en de geweigerde bron bewijzen het binnenste beleid dat u bedoelde. Verbind de client daarna opnieuw en herhaal, want de naam en het adres van de tunnelinterface kunnen tussen sessies veranderen. Als het resultaat afwijkt, corrigeert u de zonescope in plaats van de regel te verbreden.