બે પેકેટ પ્રવાહ એવા Shorewall ગેટવેમાંથી પસાર થાય છે જે OpenVPN સમાપ્ત કરે છે, અને તેમાંથી માત્ર એક જ એન્ક્રિપ્ટેડ છે. પ્રથમ એ ઇન્ટરનેટ તરફના ઇન્ટરફેસ પરના VPN શ્રોતા સુધીનું ક્લાયન્ટ ટ્રાન્સપોર્ટ છે. બીજું એ ટનલ ઇન્ટરફેસમાંથી નીકળતી ડિક્રિપ્ટેડ વિનંતી છે, જે ઓફિસ સર્વર અથવા ગેટવે પરની સેવા તરફ જાય છે. નીતિ સંપાદિત કરતા પહેલાં બંનેનું નકશો બનાવો, કારણ કે પ્રથમને સંતોષતો નિયમ બીજા માટે કંઈ કરતો નથી.

નીતિ સંપાદિત કરતા પહેલાં બે પ્રવાહ દોરો

પ્રવાહોને સ્રોત, લક્ષ્ય, પ્રોટોકોલ અને પોર્ટ સાથે પંક્તિઓ તરીકે લખો. બાહ્ય માર્ગ પર સ્રોત ક્લાયન્ટનું જાહેર સરનામું છે અને લક્ષ્ય ગેટવેનો શ્રવણ પોર્ટ છે; Shorewall તેને ઇન્ટરનેટથી ફાયરવોલ તરફના ટ્રાફિક તરીકે ગણે છે. આંતરિક માર્ગ પર સ્રોત ટનલ સરનામા શ્રેણી છે અને લક્ષ્ય મંજૂર સેવા છે. એક વ્યવસ્થાપક બંને સંભાળે તો પણ બે પંક્તિઓના માલિકો અલગ હોય છે.

FlowZone relationshipWhat to constrain
Encrypted OpenVPN transportInternet to the firewall hostThe listener's actual protocol and port
Decrypted request to a LAN serviceVPN clients to the LAN zoneOne approved server and service
Decrypted request to the gatewayVPN clients to the firewall hostOnly the local services required
Request to another VPN clientVPN clients to VPN clientsDenied unless deliberately required

પંક્તિ ઉમેરો જ્યારે વિનંતી ગેટવે પર જ સમાપ્ત થાય, જેમ કે રિઝોલ્વર અથવા વ્યવસ્થાપન ઍક્સેસ. હોસ્ટ પરની સેવા ફોરવર્ડ માર્ગને નહીં, હોસ્ટ-ઇનપુટ નીતિને અનુસરે છે. આ બંને ભેળવવાથી જ સાંકડો ટનલ નિયમ વ્યવસ્થાપન ઇન્ટરફેસને ખુલ્લો કરી દે છે.

ટનલ ઝોન અને ઇન્ટરફેસ અવકાશ સોંપો

રોડ-વોરિયર ઝોન /etc/shorewall/zones માં જાહેર થાય છે, ટનલ ઇન્ટરફેસ /etc/shorewall/interfaces માં જોડાય છે, અને બાહ્ય જોડાણ /etc/shorewall/tunnels માં વર્ણવાય છે. સ્થાપિત આવૃત્તિના સિન્ટેક્સ સાથે મેળ બેસાવો, કારણ કે કૉલમનો ક્રમ અને વિકલ્પ નામો મુખ્ય આવૃત્તિઓ વચ્ચે બદલાયા છે. માર્ગદર્શિકાનો ઉદાહરણ પોર્ટ ડેમન ખરેખર જે પોર્ટ પર સાંભળે છે તેના કરતાં અલગ પોર્ટની પરવાનગી આપવાનું કારણ નથી. ફક્ત સંખ્યાઓ મળતી હોવાથી TCP અને UDP અદલાબદલી યોગ્ય નથી.

માર્ગદર્શિકા tun+ વડે ઇન્ટરફેસને જૂથબદ્ધ કરે છે. એક કરતાં વધુ ટનલ ધરાવતા હોસ્ટ પર તે વાઇલ્ડકાર્ડ અલગ વિશ્વાસ સ્તરનું બીજું VPN એ જ ઝોનમાં મૂકી શકે છે. અવકાશને ખરેખર અસ્તિત્વમાં રહેલા ઇન્ટરફેસ સામે સમીક્ષા કરો, અને ઇન્ટરફેસ નામો હાથે સંપાદિત કરવાને બદલે નામકરણને કનેક્શન મેનેજરના જીવનચક્ર હેઠળ રાખો.

ઐતિહાસિક માર્ગદર્શિકામાં ઘણા જૂના OpenVPN રૂપરેખા નમૂનાઓ છે, અને તેની ક્રિપ્ટો સલાહ વર્તમાન જમાવટમાં નકલ કરવી જોઈએ નહીં. તેના બદલે ઝોન અને પ્રવાહનું મોડેલ ઉછીનું લો. ક્રિપ્ટોગ્રાફિક આધાર ગેટવેની જાળવેલ OpenVPN નીતિમાંથી લો.

તમે વર્ગીકૃત કરેલા માર્ગને જ પરવાનગી આપો

VPN ઝોનથી LAN સુધીની વ્યાપક સ્વીકૃતિ શરૂઆતની રૂપરેખા છે, પૂર્ણ નીતિ નથી. મંજૂર ક્લાયન્ટ સ્રોત, વાસ્તવિક સેવા સરનામું, પ્રોટોકોલ અને પોર્ટ લખો. પછી તેની ઉપરની નિયમો અને ઝોનનું મૂળભૂત મૂલ્ય વાંચો, કારણ કે સાંકડો ઉમેરો પહેલેથી મેળ ખાતી વ્યાપક પરવાનગી રદ કરતો નથી. ગેટવે હોસ્ટ તરફનો ટ્રાફિક તેના દ્વારા ફોરવર્ડ થતા ટ્રાફિકથી અલગ સંબંધ છે.

ક્લાયન્ટ-થી-ક્લાયન્ટ ટ્રાફિકને પોતાનો નિર્ણય જોઈએ. OpenVPN નું client-to-client અને Shorewall નું routeback બંને ક્લાયન્ટ એકબીજા સુધી પહોંચી શકે છે કે નહીં તેને અસર કરે છે, અને એક LAN એપ્લિકેશન ચાલે તે માટે જ કોઈપણને સક્ષમ કરવું જોઈએ નહીં. પરીક્ષણ કરતા પહેલાં અલગતા ક્યાં લાગુ થાય છે તે નક્કી કરો.

જવાબનો માર્ગ એ જ યોજનામાં રાખો. સેવા અથવા તેના રાઉટરને ટ્રાફિક ટનલ શ્રેણીમાં કેવી રીતે પાછો મોકલવો તે જાણવું જોઈએ, અથવા રચનાએ સ્રોતનું જાણી જોઈને અને ઇચ્છિત અવકાશમાં ભાષાંતર કરવું જોઈએ.

માન્ય કરો, પછી બંને માર્ગ સાબિત કરો

કંઈપણ પુનઃશરૂ કરતા પહેલાં રૂપરેખા માન્ય કરો, અને નવી નીતિ ખોટી હોય તો તે માટે સ્વતંત્ર વ્યવસ્થાપન સત્ર ખુલ્લું રાખો.

shorewall check

સ્વચ્છ તપાસ પછી રૂપરેખા લાગુ કરો અને Shorewall એ શું લોડ કર્યું તે પાછું વાંચો. આ વાંચન ચાલી રહેલી નીતિનું વર્ણન કરે છે, ફાઇલ શું કહેતી હોય તેવું લાગે છે તેનું નહીં.

shorewall show zones
ip route get 192.168.10.20

એક જ ક્લાયન્ટથી એક નવી મંજૂર વિનંતી અને એક જાણી જોઈને નકારેલી વિનંતીનું પરીક્ષણ કરો. સફળ OpenVPN હેન્ડશેક ફક્ત બાહ્ય આદાનપ્રદાન સાબિત કરે છે; મંજૂર સેવા અને નકારેલ સંસાધન તમે ઇચ્છતા હતા તે આંતરિક નીતિ સાબિત કરે છે. પછી ક્લાયન્ટ ફરી જોડો અને પુનરાવર્તન કરો, કારણ કે ટનલ ઇન્ટરફેસનું નામ અને સરનામું સત્રો વચ્ચે બદલાઈ શકે છે. પરિણામ અલગ હોય તો નિયમ પહોળો કરવાને બદલે ઝોનનો અવકાશ સુધારો.

સંબંધિત લેખો