OpenWrt VPN ઝોન, ફોરવર્ડિંગ અને માસ્કરેડિંગ: કયું જરૂરી છે?
ઝોન ઇનપુટ, ફોરવર્ડિંગ અને માસ્કરેડિંગ જુદા જુદા પ્રશ્નોના જવાબ આપે છે. WAN ઝોન ખોલતા પહેલાં નક્કી કરો કે તમારા VPN ટ્રાફિકને કયું જોઈએ છે.
VPN જ્યારે OpenWrt સાથે મળે છે ત્યારે ત્રણ ફેરફારો ભેગા થઈ જાય છે: પોર્ટ ખોલવો, ફોરવર્ડિંગની પરવાનગી આપવી અને માસ્કરેડિંગ ચાલુ કરવું. તે જુદા જુદા પ્રશ્નોના જવાબ આપે છે, અને સામાન્ય રીતે તેમાંથી ફક્ત એક જ ખરેખરી જરૂરિયાત હોય છે. જે ટ્રાફિક ભૂમિકાને એક નિયંત્રણ સંભાળે છે તે પ્રમાણે દરેક નિયંત્રણ વાંચવાથી અનુમાન નિર્ણયમાં બદલાય છે, અને ફેરફાર ખોટો હોય ત્યારે કયું લક્ષણ અપેક્ષિત છે તે પણ જણાવે છે. જે ભૂમિકા નિષ્ફળ ગઈ તેનું નામ આપીને શરૂ કરો, તમે યાદ રાખેલું ચેકબોક્સ નહીં.
કોઈ નિયંત્રણને સ્પર્શ કરતા પહેલાં ટ્રાફિક ભૂમિકાનું નામ આપો
ઝોન ઇનપુટ નક્કી કરે છે કે રાઉટર સુધી શું પહોંચી શકે. ઝોન આઉટપુટ રાઉટર પોતે બનાવેલા ટ્રાફિકને આવરે છે, ઝોન ફોરવર્ડિંગ એ ઝોનમાંથી પસાર થતા ટ્રાફિક માટેનું મૂળભૂત મૂલ્ય છે, અને માસ્કરેડિંગ નક્કી કરે છે કે બહાર જતી વખતે સ્રોત સરનામું ફરીથી લખાય છે કે નહીં. આ ચાર જુદા પ્રશ્નો છે, અને ઝોન નીતિ એક જ મૂલ્ય સાથે એકસાથે ચારેયનો જવાબ આપે છે, તેથી આખા ઝોનમાંનો ફેરફાર એક જડ સાધન છે. નામવાળો નિયમ બાકીનાને સ્પર્શ કર્યા વિના તેમાંથી એકનો જવાબ આપી શકે છે.
ઉપયોગી નકશો ટ્રાફિક ભૂમિકા પ્રમાણેનો છે, કારણ કે કંઈક નિષ્ફળ જાય ત્યારે તમે તે જ જોઈ શકો છો. નીચેની દરેક ભૂમિકા પાસે તેને નક્કી કરતું એક નિયંત્રણ અને તે તરફ ઈશારો કરતું એક લક્ષણ છે:
| Traffic role | Control that decides it | Where it lives in the config | Symptom when it is wrong |
|---|---|---|---|
| A client reaching a listener on the router | Input policy of the zone that carries the connection, or a rule for the port | option input in the zone stanza, or a named rule | The handshake never completes and the tunnel log says nothing |
| A tunnel client reaching the router itself | Input policy of the tunnel zone | option input in the VPN zone | A ping to the gateway fails |
| A tunnel client reaching another LAN host | Forwarding from the tunnel zone to the LAN zone | config forwarding plus the zone assignment | The gateway answers and the file share times out |
| The router's own traffic leaving the WAN | Output policy, and translation if the far side needs it | option output and option masq | The tunnel never establishes, or replies vanish |
રાઉટર પર સાંભળતી સેવાને એક સાંકડો ઇનપુટ નિયમ જોઈએ
રાઉટર પરનું OpenVPN સર્વર રાઉટરને સંબોધિત ટ્રાફિક મેળવે છે, તેથી તેનું બહારનું જોડાણ તેને વહન કરતા ઝોનની ઇનપુટ નીતિ પર આધાર રાખે છે. ગોઠવેલા ટ્રાન્સપોર્ટ અને પોર્ટને મંજૂરી આપો અને તે ઝોનમાં બાકીનું બધું નકારેલું રાખો. એક પોર્ટ નિયમ આખા ઝોનની મંજૂરી કરતાં ઘણો નાનો ફેરફાર છે, અને એક વર્ષ પછી પણ તમે જે સમજાવી શકો તે એ જ છે.
બે વસ્તુઓ આ નિયમને રાખવા માટે સુરક્ષિત બનાવે છે: તે તે પોર્ટનું નામ આપે છે જે સેવા ખરેખર વાપરે છે, અને તે ઝોનની વ્યાખ્યાની બાજુમાં રહે છે જેથી આગળની વ્યક્તિ જોઈ શકે કે તે કેમ છે. નીચેની લાઇનો ફક્ત આકાર છે, જેમાં પોર્ટ સર્વર પર ગોઠવેલા મૂલ્યનું સ્થાન લે છે. સેવા ખસે ત્યારે તે પોર્ટ બંને જગ્યાએ બદલો, કારણ કે જૂના પર રહેલો નિયમ ઓડિટ સુધી અદૃશ્ય રહે છે.
config zone
option name 'wan'
option input 'REJECT'
option forward 'REJECT'
option output 'ACCEPT'
option masq '1'
config rule
option name 'allow-openvpn'
option src 'wan'
option proto 'udp'
option dest_port '1194'
option target 'ACCEPT'ફરી લોડ કરતા પહેલાં ચકાસો, કારણ કે ફાયરવોલ ફાઇલમાંની વાક્યરચના ભૂલ રાઉટરને કામ કરતા નિયમસમૂહ વિના મૂકી શકે છે. fw4 વાપરતી આવૃત્તિમાં ચકાસણી અલગ આદેશ છે, અને તે તૂટેલા ખંડને શાંતિથી સ્વીકારવાને બદલે મોટેથી નિષ્ફળ જાય છે. ચકાસણી પસાર થયા પછી જ ફરી લોડ કરો, અને અગાઉની ફાઇલ જ્યાં પાછી મૂકી શકો ત્યાં રાખો.
fw4 check
service firewall reloadક્લાયંટની વિનંતી ઇનપુટ નહીં, ફોરવર્ડિંગમાંથી પસાર થાય છે
પ્રમાણીકરણ પછી, LAN સેવા માંગતા ટનલ ક્લાયંટની વિનંતી ફોરવર્ડ કરેલો પ્રવાહ બનાવે છે, તેથી તેને નક્કી કરતું નિયંત્રણ ટનલ ઝોન અને LAN ઝોન વચ્ચેનો ફોરવર્ડિંગ સંબંધ છે. ટનલ ઇન્ટરફેસને ઇચ્છિત ઝોનમાં સોંપો, પછી દિશા, સ્રોત અને સેવા જાહેર કરો. ઝોન સોંપણી એ જ ફોરવર્ડિંગ નિયમને અર્થ આપે છે, અને બંને સાથે વાંચવાથી જ સમજાય છે. જે ફોરવર્ડિંગ સંબંધ ટનલ ઝોનને સ્રોત અને LAN ઝોનને લક્ષ્ય કહે છે તે એક સુવિચારી નિર્ણય તરીકે વંચાય છે, જ્યારે આખા ઝોનની બે મંજૂરીઓ અકસ્માત તરીકે વંચાય છે.
રાઉટર સુધી પહોંચવા માટે હજી ઇનપુટ માર્ગ વપરાય છે, તેથી ગેટવેને ping તેની પાછળની ફાઇલ શેરિંગ વિશે કંઈ કહેતું નથી. તે બે નિષ્ફળતાઓ જુદા ખંડોમાં રહે છે અને જુદા સંપાદનોથી સુધારાય છે. બંનેમાંથી કોઈપણ બદલતા પહેલાં બંને માર્ગ અલગ લખો.
માસ્કરેડિંગ એ રાઉટિંગ નિર્ણય છે, પરવાનગી નહીં
માસ્કરેડિંગ પસંદ કરેલા બહાર જતા ટ્રાફિકનું સ્રોત સરનામું ફરીથી લખે છે. તે એવી નિકાસ રચના બચાવી શકે છે જ્યાં દૂરના છેડે પાછા જવાનો માર્ગ નથી, અને તે સરનામાં લોગ કરતી કે સરનામા પ્રમાણે અધિકૃત કરતી કોઈપણ સેવાથી વ્યક્તિગત ક્લાયંટના સરનામાં પણ છુપાવે છે. તેને બંધ કરવું એ પાછા જવાના માર્ગ વિશેની રાઉટિંગ પસંદગી છે, અંદરનું છિદ્ર બંધ કરતો સુરક્ષા સ્વિચ નહીં. જે ટનલ અનુવાદ ચાલુ હોય ત્યારે કામ કરે છે અને બંધ કરવાની ક્ષણે નિષ્ફળ જાય છે તેમાં સામાન્ય રીતે પાછા જવાનો માર્ગ ખૂટે છે, ફાયરવોલ નિયમ નહીં.
રાઉટ કરેલા વિકલ્પને અનુવાદને બદલે દૂરના છેડે પાછા જવાનો માર્ગ જોઈએ. બંનેમાંથી કોઈ વિકલ્પ ફાયરવોલ પરવાનગી કે એપ્લિકેશન ખાતું પૂરું પાડતું નથી, તેથી માસ્કરેડિંગ બંધ કરવાથી કંઈ પણ પહોંચી ન શકતા ટનલ ક્લાયંટને લગભગ ક્યારેય સુધારતું નથી. IPv4 અને IPv6 નીતિને પણ અલગ રીતે જુઓ, કારણ કે એક અનુવાદ સેટિંગ બંને કુટુંબોનું વર્ણન કરતું નથી.
મંજૂર અને નકારેલી વિનંતીથી નિર્ણય સાબિત કરો
એક વિનંતી મોકલો જે મંજૂર થવી જોઈએ અને એક જે નકારવી જોઈએ, પછી દરેક નિર્ણય લેનારું નિયંત્રણ ઓળખો. જે પૃષ્ઠ આકસ્મિક રીતે લોડ થાય તે પુરાવો નથી; પુરાવો એ નિયમ છે જે મેળ ખાયો, જે સાંકળમાં મેળ ખાયો ત્યાં. નકાર મંજૂરી જેટલો જ મહત્વનો છે, કારણ કે તે દર્શાવે છે કે નીતિ કંઈક કરે છે, બધું મંજૂર હોવાને બદલે.
વર્તમાન આવૃત્તિમાં બે આદેશ તમને તે પુરાવો આપે છે. વિનંતી સ્વીકારાય ત્યારે મેળ ખાતા નિયમનો કાઉન્ટર ખસે છે, અને જો તમે નિયમ માટે લોગિંગ ચાલુ કર્યું હોય તો લોગ ડ્રોપ બતાવે છે:
nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'કોઈપણ ફાયરવોલ નીતિ બદલતા પહેલાં એવો સંચાલન માર્ગ રાખો જે હજી વાપરી શકો, અને ગોઠવણીના માલિકની ચકાસણી અને રોલબેક પ્રક્રિયા અનુસરો. જે ફેરફાર તમને રાઉટરની બહાર તાળું મારે તે પરીક્ષણ પરિણામ નથી, તે બીજી ઘટના છે. દરેક નિરીક્ષણની બાજુમાં ઝોન અને ટ્રાફિક ભૂમિકા નોંધો, જેથી પરિણામની જોડી નીતિ સમજાવે, નસીબદાર પૃષ્ઠ લોડનું વર્ણન ન કરે.