VPN ક્લાયન્ટ્સ અને LAN: ક્યારે અલગ ઝોન વાપરવો

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

ઝોનનું નામ કંઈપણ એન્ક્રિપ્ટ કરતું નથી કે વપરાશકર્તાને પ્રમાણિત કરતું નથી. તે ફક્ત ફાયરવોલના નીતિ મોડેલ માટે ઇન્ટરફેસને જૂથબદ્ધ કરે છે.

ઝોન સભ્યપદ ખરેખર શું નિયંત્રિત કરે છે

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

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

તે ભેદ જ અલગ ઝોન ઉપયોગી હોવાનું કારણ છે: તમે દરેક દિશા અને દરેક ભૂમિકા સ્પષ્ટ રીતે જણાવી શકો છો. દરેક નિયમની બાજુમાં દિશા લખો.

નિર્ણય એક: ઇનપુટ, ફોરવર્ડ કે બંને

જો દૂરસ્થ ક્લાયન્ટને રાઉટરથી DNSની જરૂર હોય, તો ફક્ત તે સેવા માટે ઇનપુટ મંજૂર કરો. જો તેમને ફાઇલ સર્વર સુધી પહોંચવું હોય, તો તે લક્ષ્ય તરફ ફોરવર્ડ મંજૂર કરો. મોટાભાગની VPN ડિઝાઇનને બંનેની જરૂર હોય છે, પણ જુદી જુદી સેવાઓ માટે.

દરેક સ્થાનિક સેવા માટે વ્યાપક ઇનપુટ ઍક્સેસ લગભગ ક્યારેય જરૂરી નથી. રાઉટર વ્યવસ્થાપનને ઍપ્લિકેશન ઍક્સેસથી અલગ નિર્ણય તરીકે ગણો. જો રાઉટરે ફક્ત DNSનો જવાબ આપવાનો હોય, તો તે એક જ પરવાનગી લખો અને બાકીનું બંધ રાખો.

નિર્ણય બે: દૂરસ્થ ક્લાયન્ટને કયા સંસાધનોની જરૂર છે

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

વ્યવસ્થાપન ઇન્ટરફેસને સામાન્ય ઍપ્લિકેશન ઍક્સેસથી અલગ રાખો. વિકિ સુધી પહોંચતા દૂરસ્થ ક્લાયન્ટને તેના કારણે રાઉટરનું એડમિન પૃષ્ઠ કે હાઇપરવાઇઝર કન્સોલની જરૂર નથી.

જો મંજૂર કરેલું લક્ષ્ય આગળ ફોરવર્ડ કરી શકે, તો ઝોનની સીમા ફાયરવોલ પર જ અટકે છે, લક્ષ્ય આગળ શું કરે છે ત્યાં નહીં.

નિર્ણય ત્રણ: સીમા કેવી રીતે સાબિત કરશો

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

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

નેટવર્ક વધે ત્યારે સભ્યપદ અને નિયમોનો હેતુ દસ્તાવેજ કરો. નવું જોડાયેલું ઇન્ટરફેસ ફક્ત એટલા માટે વિશેષાધિકારો વારસામાં ન લે કે કોઈએ તેને અનુકૂળ ઝોન નામ આપ્યું છે.