Shorewall-zonoj por la du OpenVPN-paketvojoj
Apartigu la ĉifritan OpenVPN-transporton disde la malĉifrita klienta trafiko, donu al la tunelo propran zonon kaj permesu nur tiun solan servon, kiun la kliento bezonas.
Du paketfluoj trairas Shorewall-kluzon, kiu finas OpenVPN, kaj nur unu el ili estas ĉifrita. La unua estas la transporto de la kliento al la VPN-auskultanto sur la interreton rigardanta interfaco. La dua estas la malĉifrita peto, kiu forlasas la tunelan interfacon al oficeja servilo aŭ servo sur la kluzo. Mapu ambaŭ antaŭ ol redakti la politikon, ĉar regulo, kiu kontentigas la unuan, faras nenion por la dua.
Desegnu la du fluojn antaŭ ol redakti la politikon
Skribu la fluojn kiel vicojn kun fonto, celo, protokolo kaj pordo. Sur la ekstera vojo la fonto estas la publika adreso de la kliento kaj la celo estas la auskulta pordo de la kluzo; Shorewall traktas tion kiel trafikon de interreto al fajroŝirmilo. Sur la interna vojo la fonto estas la tunela adresaro kaj la celo estas la aprobita servo. La du vicoj havas malsamajn posedantojn eĉ kiam unu administranto prizorgas ambaŭ.
| 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 |
Aldonu vicon nur se la peto finiĝas sur la kluzo mem, ekzemple aliro al solvilo aŭ administrado. Servo sur la gastiganto sekvas la enigan politikon de la gastiganto, ne la plusenditan vojon. Ĝuste miksado de la du kaŭzas, ke mallarĝa tunela regulo malkaŝas administran interfacon.
Attribuu la tunelan zonon kaj la interfacan amplekson
La zono de la migranta uzanto deklariĝas en /etc/shorewall/zones, la tunela interfaco aldoniĝas en /etc/shorewall/interfaces, kaj la ekstera konekto priskribiĝas en /etc/shorewall/tunnels. Konformiĝu al la sintakso de la instalita eldono, ĉar la kolumna ordo kaj la nomoj de opcioj ŝanĝiĝis inter ĉefaj versioj. La ekzempla pordo de la gvidilo ne estas kialo permesi alian pordon ol tiu, sur kiu la demono fakte auskultas. TCP kaj UDP ne estas interŝanĝeblaj nur ĉar la nombroj kongruas.
La gvidilo grupigas interfacojn per tun+. Sur gastiganto kun pli ol unu tunelo tiu ĵokera signo povas meti duan VPN-on de alia fida nivelo en la saman zonon. Revizu la amplekson kontraŭ la interfacoj, kiuj fakte ekzistas, kaj tenu la nomadon sub la vivociklo de la konekta administrilo anstataŭ redakti interfacajn nomojn permane.
La historia gvidilo enhavas multe pli malnovajn ekzemplojn de OpenVPN-agordo, kaj ĝiaj kriptaj konsiloj ne kopiĝu en nunan enmeton. Pruntu anstataŭe la zonan kaj fluan modelon. Prenu la kriptografian bazlinion el la prizorgata OpenVPN-politiko de la kluzo.
Permesu nur la vojon, kiun vi klasifikis
Vasta akcepto de la VPN-zono al la LAN estas komenca skemo, ne finita politiko. Skribu la permesitan klientan fonton, la faktan servan adreson, la protokolon kaj la pordon. Poste legu la regulojn super ĝi kaj la zonan defaŭlton, ĉar mallarĝa aldono ne nuligas vastan permeson, kiu jam kongruas. Trafiko al la kluzo-gastiganto estas aparta rilato de trafiko plusendata tra ĝi.
Klient-al-klienta trafiko bezonas propran decidon. La client-to-client de OpenVPN kaj la routeback de Shorewall ambaŭ influas, ĉu klientoj povas atingi unu la alian, kaj neniu el ili aktivigu nur por igi unu LAN-aplikaĵon funkcii. Decidu, kie izolado plenumiĝas antaŭ ol vi testas ĝin.
Tenu la respondan vojon en la sama plano. La servo aŭ ĝia enkursigilo devas scii, kiel redoni trafikon al la tunela adresaro, aŭ la dezajno devas traduki la fonton intence kaj ene de la celita amplekso.
Validigu, poste pruvu ambaŭ vojojn
Validigu la agordon antaŭ ol restartigi ion ajn, kaj tenu sendependan administran sean malfermita se la nova politiko malĝustas.
shorewall checkPost pura kontrolo apliku la agordon kaj relegu, kion Shorewall ŝargis. Tiuj legoj priskribas la funkciantan politikon, ne tion, kion dosiero ŝajnas diri.
shorewall show zones
ip route get 192.168.10.20Testu unu novan permesitan peton kaj unu intence rifuzitan peton el la sama kliento. Sukcesa OpenVPN-manpremo pruvas nur la eksteran interŝanĝon; la permesita servo kaj la rifuzita rimedo pruvas la internan politikon, kiun vi celis. Poste rekonektu la klienton kaj ripetu, ĉar la nomo kaj adreso de la tunela interfaco povas ŝanĝiĝi inter seancoj. Se la rezulto diferencas, riparu la amplekson de la zono anstataŭ vastigi la regulon.