Shorewall-zoner för de två OpenVPN-paketvägarna
Separera den krypterade OpenVPN-transporten från den dekrypterade klienttrafiken, ge tunneln en egen zon och tillåt bara den enda tjänst som klienten behöver.
Två paketflöden korsar en Shorewall-gateway som terminerar OpenVPN, och bara ett av dem är krypterat. Det första är klientens transport till VPN-lyssnaren på det internetvända gränssnittet. Det andra är den dekrypterade begäran som lämnar tunnelgränssnittet till en kontorsserver eller en tjänst på gatewayen. Kartlägg båda innan du redigerar policyn, eftersom en regel som uppfyller den första inte gör något för den andra.
Rita de två flödena innan du redigerar policyn
Skriv flödena som rader med källa, destination, protokoll och port. På den yttre vägen är källan klientens publika adress och destinationen gatewayens lyssnarport; Shorewall behandlar det som trafik från internet till brandväggen. På den inre vägen är källan tunnelns adressområde och destinationen den godkända tjänsten. De två raderna har olika ägare även när en administratör underhåller båda.
| 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 |
Lägg bara till en rad om begäran slutar på gatewayen själv, till exempel åtkomst till resolvern eller administrationen. En tjänst på värden följer värdens ingångspolicy, inte den vidarebefordrade vägen. Att blanda de två är hur en snäv tunnelregel till slut exponerar ett administratörsgränssnitt.
Tilldela tunnelzonen och gränssnittets omfång
Road-warrior-zonen deklareras i /etc/shorewall/zones, tunnelgränssnittet kopplas i /etc/shorewall/interfaces och den yttre förbindelsen beskrivs i /etc/shorewall/tunnels. Anpassa dig till syntaxen i den installerade utgåvan, eftersom kolumnordning och alternativnamn har ändrats mellan huvudversioner. Guidens exempelport är inte skäl att tillåta en annan port än den som daemonen faktiskt lyssnar på. TCP och UDP är inte utbytbara bara för att siffrorna stämmer.
Guiden grupperar gränssnitt med tun+. På en värd med mer än en tunnel kan det jokertecknet placera ett andra VPN med en annan förtroendenivå i samma zon. Granska omfånget mot de gränssnitt som faktiskt finns, och håll namngivningen under livscykeln för anslutningshanteraren i stället för att redigera gränssnittsnamn för hand.
Den historiska guiden innehåller mycket äldre OpenVPN-konfigurationsexempel, och dess kryptoråd bör inte kopieras till en aktuell driftsättning. Låna i stället zon- och flödesmodellen. Ta den kryptografiska grunden från gatewayens underhållna OpenVPN-policy.
Tillåt bara den väg du klassificerade
En bred acceptans från VPN-zonen till LAN är ett startdiagram, inte en färdig policy. Skriv den tillåtna klientkällan, tjänstens faktiska adress, protokollet och porten. Läs sedan reglerna ovanför och zonens standardvärde, eftersom ett snävt tillägg inte upphäver ett brett tillstånd som redan matchar. Trafik till gatewayvärden är en separat relation från trafik som vidarebefordras genom den.
Trafik mellan klienter behöver sitt eget beslut. OpenVPN:s client-to-client och Shorewalls routeback påverkar båda om klienter kan nå varandra, och inget av dem bör aktiveras bara för att få en LAN-applikation att fungera. Bestäm var isoleringen upprätthålls innan du testar den.
Håll returvägen i samma plan. Tjänsten eller dess router måste veta hur trafiken returneras till tunnelområdet, eller så måste designen översätta källan medvetet och inom det avsedda omfånget.
Validera och bevisa sedan båda vägarna
Validera konfigurationen innan du startar om något, och håll en oberoende administrativ session öppen ifall den nya policyn är fel.
shorewall checkEfter en ren kontroll tillämpar du konfigurationen och läser tillbaka vad Shorewall laddade. Dessa läsningar beskriver den körande policyn snarare än vad en fil verkar säga.
shorewall show zones
ip route get 192.168.10.20Testa en ny tillåten begäran och en avsiktligt nekad begäran från samma klient. Ett lyckat OpenVPN-handskakning bevisar bara det yttre utbytet; den tillåtna tjänsten och den nekade resursen bevisar den inre policy du avsåg. Anslut sedan klienten igen och upprepa, eftersom tunnelgränssnittets namn och adress kan ändras mellan sessioner. Om resultatet skiljer sig, rätta zonens omfång i stället för att bredda regeln.