રાઉટર VPN નિયમો: સ્રોત અને લક્ષ્યને મેળવો
રાઉટર પરના VPN નિયમના બે છેડા હોય છે: જે ઉપકરણ ટ્રાફિક મોકલે છે અને જે લક્ષ્ય ટનલનો ઉપયોગ કરવો જોઈએ. પહેલાં છેદન અને ફોલબેક નક્કી કરો.
રાઉટર ખરીદીના પૃષ્ઠો VPN રાઉટિંગને એક ચેકબોક્સ તરીકે બતાવે છે, અને આ વાક્ય ત્રણ અલગ પ્રશ્નો છુપાવે છે. નિયમ ટ્રાફિક મોકલતા ઉપકરણ સાથે મેળ ખાય છે, તેને સ્વીકારતા સર્વર સાથે મેળ ખાય છે, કે બંને સાથે? કોઈપણ સાથે ન મેળ ખાતા ટ્રાફિકનું શું થાય છે? અને જ્યારે બે નિયમો ઓવરલેપ થાય છે, ત્યારે કોણ જીતે છે? જવાબને સ્રોત અને લક્ષ્યની જોડી તરીકે લખવાથી અસ્પષ્ટ સુવિધા-સૂચિ પરીક્ષણક્ષમ ડિઝાઇન બને છે.
સુવિધાનું નામ બે છેડા છુપાવે છે
જે મીડિયા પ્લેયર ટનલનો ઉપયોગ કરવો જોઈએ તે સ્રોત-મેળ છે. જે ખાનગી ઓફિસ પ્રીફિક્સ ટનલ દ્વારા પહોંચવા યોગ્ય હોવું જોઈએ તે લક્ષ્ય-મેળ છે. જે વર્કસ્ટેશન ફક્ત એક સેવા માટે ટનલનો ઉપયોગ કરવો જોઈએ તે બંને છે, અને તે છેદન જે કેસ મોટાભાગનું ગ્રાહક ફર્મવેર ખરાબ રીતે સંભાળે છે છે.
ઉત્પાદનોની તુલના કરતા પહેલાં જરૂરિયાતને જોડી તરીકે લખો. તે જ જોડી પછી તમે પરીક્ષણ કરશો.
જે ઉત્પાદન ઉપકરણ-સૂચિ અથવા વૈશ્વિક લક્ષ્ય-સૂચિ આપે છે તે કદાચ «ફક્ત આ ઉપકરણ, ફક્ત આ લક્ષ્યો» વ્યક્ત કરી શકતું નથી. આ અંતર દેખાવનું નથી: વૈશ્વિક લક્ષ્ય-નિયમ તે સાઇટ માટે દરેક ઉપકરણનો ટ્રાફિક ટનલ દ્વારા મોકલે છે, અને ઉપકરણ-નિયમ તે ઉપકરણનો બધો ટ્રાફિક મોકલે છે. બંનેમાંથી કોઈ જરૂરિયાત નથી. સ્ક્રીન પર ભરોસો કરતા પહેલાં બે ઉપકરણો સાથે તે કેસનું પરીક્ષણ કરો.
નિયમને છેદન તરીકે બનાવો
કોષ્ટક ડિઝાઇનને પ્રામાણિક રાખે છે. દૃશ્ય ડાબી બાજુ મૂકો, પછી પ્રેષક-મેળ અને લક્ષ્ય-મેળને અલગ રીતે નામ આપો:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
ત્રીજી પંક્તિ રસપ્રદ છે, કારણ કે તેને એકસાથે બંને અર્ધ ભાગની જરૂર છે. જો ફર્મવેર ફક્ત એક અક્ષ વ્યક્ત કરી શકે, તો જરૂરિયાતને બે નિયમોમાં વિભાજિત કરવી પડશે અથવા જે કરી શકે તેવા ઉપકરણમાં ખસેડવી પડશે.
સ્રોતની ઓળખ સ્થિર રાખો. DHCP રિઝર્વેશન, સમર્પિત સેગમેન્ટ અથવા ઉપકરણ-ઓળખ પદ્ધતિ બધું કામ કરે છે, પરંતુ લીઝ પૂરી થયા પછી બદલાતું સરનામું કામ કરતું નથી. IPv6 સામેલ કરો, કારણ કે એક IPv4 સરનામું ઉપકરણનો બધો ટ્રાફિક ઓળખતું નથી.
અગ્રતા ઓવરલેપ નક્કી કરે છે
નિયમોનો ઓવરલેપ સામાન્ય છે. વિશાળ ઉપકરણ-નિયમ અને સાંકડો લક્ષ્ય-નિયમ બંને એક જ પ્રવાહનું વર્ણન કરી શકે છે, અને દસ્તાવેજીકૃત અગ્રતા-ક્રમ નક્કી કરે છે કે કોણ જીતે છે. આકર્ષક સેટિંગ્સ સ્ક્રીન તમને તે ક્રમ કહેતી નથી.
ક્રમ અને મેળ ન થતા કેસ માટે માર્ગદર્શિકા વાંચો, પછી તમે જોઈ શકો તેવા ટ્રાફિક સાથે બંનેનું પરીક્ષણ કરો:
ip rule show
ip route get 203.0.113.10જો દસ્તાવેજીકરણ ક્રમ જણાવતું નથી, તો ધારો કે સાંકડો નિયમ જીતી ન પણે, અને તે મુજબ ડિઝાઇન કરો. જે બે નિયમોમાં સંઘર્ષ થઈ શકતો નથી તે અગ્રતા અલિખિત હોય તેવા એક ચતુર નિયમ કરતાં સમર્થન કરવા સરળ છે.
નામોને રિફ્રેશ નીતિની જરૂર છે
ડોમેન તરીકે લખાયેલું લક્ષ્ય જાળવણીની સમસ્યા ઉમેરે છે. રાઉટરે તેને ઉકેલવું પડે, મેપિંગ રિફ્રેશ કરવું પડે, અનેક સરનામાં અને સબડોમેન સંભાળવા પડે, અને અપેક્ષિત રિઝોલ્વરને ટાળતા એપ્લિકેશન DNSનો સામનો કરવો પડે.
એક શોધ-પરિણામને IP નિયમમાં કૉપિ કરવું સ્નેપશોટ છે, ડોમેન નીતિ નથી.
નિયમ ખોટો થાય તે પહેલાં જવાબ કેટલો જૂનો હોઈ શકે, અને રિઝોલ્યુશન નિષ્ફળ જાય ત્યારે રાઉટર શું કરે તે નક્કી કરો. છેલ્લું જાણીતું સરનામું રાખતો નિયમ સેવા-સ્થળાંતર પછી પણ ટકી શકે; એન્ટ્રી કાઢી નાખતો નિયમ ટનલિંગ ચુપચાપ બંધ કરી શકે. બંને વર્તન સ્વીકાર્ય છે જો તે નિયમની બાજુમાં લખાયેલું હોય.
અનુપલબ્ધ સ્થિતિ વ્યાખ્યાયિત કરો
રૂટ પસંદગી ફક્ત-VPN ટ્રાફિક ફરજિયાત કરતી નથી. ટનલ બંધ હોય ત્યારે રાઉટર પ્રવાહને અવરોધી શકે, સીધો મોકલી શકે અથવા બીજી ટનલ વાપરી શકે, અને દરેક પસંદગીની નિષ્ફળતાની છાપ અલગ હોય છે.
જરૂરિયાતને કઈ જોઈએ તે નક્કી કરો, પછી ટનલ બંધ કરીને અને પ્રવાહ જોઈને તેને ચકાસો:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10રાઉટરમાંથી ઉદ્ભવતો ટ્રાફિક અલગ ક્ષેત્ર છે. DNS ફોરવર્ડિંગ, અપડેટ-તપાસ અને મોનિટરિંગ ઉપકરણના સ્રોત-મેળને વારસામાં ન લેતાં રાઉટરમાંથી જ નવા પ્રવાહ શરૂ કરી શકે છે. તે પ્રવાહોને સ્પષ્ટ રીતે ધ્યાનમાં લો, નહીં તો લોગમાં અસ્પષ્ટ લીક તરીકે દેખાશે.