Shorewall-sônes foar de twa OpenVPN-pakketrûtes
Skied it fersifere OpenVPN-transport fan ûntsifere klantferkear, jou de tunnel syn eigen sône en lit allinnich de iene tsjinst troch dy't de klant nedich hat.
Twa pakketstreamen kruse in Shorewall-gateway dy't OpenVPN beëiniget, en mar ien fan beide is fersifere. De earste is it transport fan de klant nei de VPN-harker op de ynternet-rjochte ynterface. De twadde is it ûntsifere fersyk dat de tunnel-ynterface ferlit nei in kantoarserfer as in tsjinst op de gateway. Kartearje beide foardat jo it belied bewurkje, want in regel dy't de earste befrediget docht neat foar de twadde.
Tekenje de twa streamen foardat jo it belied bewurkje
Skriuw de streamen as rigen mei boarne, bestimming, protokol en poarte. Op de bûtenste rûte is de boarne it iepenbiere adres fan de klant en de bestimming de harkpoarte fan de gateway; Shorewall behannelet dat as ferkear fan ynternet nei de firewall. Op de binnenste rûte is de boarne it tunneladresberik en de bestimming de goedkarde tsjinst. De twa rigen hawwe ferskate eigners, sels as ien behearder beide ûnderhâldt.
| 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 |
Foegje allinnich in rige ta as it fersyk op de gateway sels einiget, lykas tagong ta de resolver of behear. In tsjinst op de host folget it host-ynfierbelied, net it trochstjoerde paad. It mingen fan beide is hoe't in smelle tunnelregel úteinlik in behearynterface bleatleit.
Wys de tunnelsône en it ynterfaceberik ta
De reizger-sône wurdt ferklearre yn /etc/shorewall/zones, de tunnel-ynterface wurdt tafoege yn /etc/shorewall/interfaces, en de bûtenferbining wurdt beskreaun yn /etc/shorewall/tunnels. Pas jo oan de syntaksis fan de ynstalleare ferzje, want kolomfolchoarder en opsjenammen binne feroare tusken haadferzjes. De foarbyldpoarte fan de gids is gjin reden om in oare poarte ta te stean as dy't de daemon eins beharket. TCP en UDP binne net útwikselber allinnich om't de sifers oerienkomme.
De gids groepearret ynterfaces mei tun+. Op in host mei mear as ien tunnel kin dat jokerteken in twadde VPN fan in oar fertrouwensnivo yn deselde sône pleatse. Besjoch it berik tsjin de ynterfaces dy't eins bestean, en hâld de nammentjouwing ûnder de libbenssyklus fan de ferbiningbehearder ynstee fan ynterfacenammen mei de hân te bewurkjen.
De histoaryske gids befettet folle âldere OpenVPN-konfiguraasjefoarbylden, en har krypto-advys moat net yn in hjoeddeistige útrulling kopiaasje wurde. Lien ynstee it sône- en streammodel. Nim de kryptografyske basis út it ûnderhâlden OpenVPN-belied fan de gateway.
Lit allinnich it paad troch dat jo klassifisearre hawwe
In brede akseptaasje fan VPN-sône nei LAN is in begjinschema, net in ôfmakke belied. Skriuw de tastiene klantboarne, it werklike tsjinstadres, it protokol en de poarte. Lês dan de regels derboppe en it sône-standert, want in smelle tafoeging annulearret gjin brede tastimming dy't al oerienkomt. Ferkear nei de gateway-host is in aparte relaasje fan ferkear dat dertroch trochstjoerd wurdt.
Ferkear tusken klanten freget syn eigen beslút. OpenVPN syn client-to-client en Shorewall syn routeback beynfloedzje beide oft klanten elkoar berikke kinne, en gjin fan beide moat oanset wurde allinnich om ien LAN-applikaasje wurkje te litten. Beslis wêr't isolaasje ôftwongen wurdt foardat jo it test.
Hâld it antwurdpaad yn itselde plan. De tsjinst of syn router moat witte hoe't it ferkear nei it tunnelberik weromkomt, of it ûntwerp moat de boarne bewust en binnen it bedoelde berik oersette.
Falidearje, en bewize dan beide paden
Falidearje de konfiguraasje foardat jo wat dan ek werstarte, en hâld in ûnôfhinklike behearsesje iepen foar it gefal dat it nije belied ferkeard is.
shorewall check
Nei in skjinne kontrôle, pas de konfiguraasje ta en lês werom wat Shorewall laden hat. Dizze lêzingen beskriuwe it rinnende belied ynstee fan wat in bestân liket te sizzen.
shorewall show zones
ip route get 192.168.10.20
Test ien nij tastien fersyk en ien bewust wegere fersyk fan deselde klant. In suksesfolle OpenVPN-hânskikking bewizet allinnich de bûtenste útwikseling; de tastiene tsjinst en it wegere boarnemateriaal bewize it binnenste belied dat jo bedoelden. Ferbyn dan de klant opnij en werhelje, want de namme en it adres fan de tunnel-ynterface kinne tusken sesjes feroarje. As it resultaat oars is, reparearje it sôneberik ynstee fan de regel te ferbreedzjen.