OpenWrt પર આખા LAN માટે OpenVPN ક્લાયન્ટ: કામ કરતો ક્રમ

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

ટનલમાં શું વહેંચાય તે નક્કી કરો

Wi-Fi અને DHCP આપતું રાઉટર પોતે જ ક્લાયન્ટ ચલાવી શકે છે. તેનાથી જોડાયેલું દરેક ઉપકરણ કોઈ પણ પ્રતિ-ઉપકરણ સેટઅપ વિના ટનલ પાછળ આવી જાય છે, અને મોટાભાગની નાની સાઇટ્સ આ જ ગોઠવણ ઇચ્છે છે. ટનલ તૂટે ત્યારે સૌથી મોટી અસર પણ આ જ ગોઠવણમાં થાય છે, કારણ કે દરેક ઉપકરણ એકસાથે પોતાનો માર્ગ ગુમાવે છે. LAN પર કોઈ પણ બહાર જવાનો કાર્યકારી માર્ગ રાખતું નથી.

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

બંને રીતે, LAN સબનેટને અલગ રાખો. સમાન રેન્જ બનાવે છે કે એક બાજુ સીધી જોડાયેલી દેખાય, અને તેમાંથી ઊભું થતું બ્લેક હોલ VPNની ખામી જેવું લાગે છે કલાકો સુધી.

ટનલને એક માલિક આપો

ટનલને નામ, ઉપકરણ અને પોતાનો કોઈ પ્રોટોકોલ ન હોય તેવા નેટવર્ક ઇન્ટરફેસ તરીકે જાહેર કરો. પછી નેટવર્ક સિસ્ટમ ઉપકરણ બનાવે છે અને સંભાળે છે, અને પછીનું બધું ઇન્ટરફેસને ઉપકરણને બદલે નામથી સંદર્ભિત કરે છે. તે જ ઝોનને તેને શોધવા દે છે.

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

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

ઝોન બનાવો, પછી તેમાં ફોરવર્ડ કરો

ફાયરવોલ ઝોન એ જગ્યા છે જ્યાં નીતિ રહે છે: ઇનપુટ, આઉટપુટ, ફોરવર્ડ અને માસ્કરેડ. કોઈ ઝોનમાં ન હોય તેવી ટનલ તમે પસંદ ન કરેલા ડિફોલ્ટ દ્વારા સંચાલિત થાય છે, જે રાઉટર ક્લાયન્ટને ભાગ્યે જ જોઈએ છે. નીચેની સ્ટેન્ઝા ઇન્ટરફેસ જાહેર કરે છે, તેને ઝોનમાં મૂકે છે અને LAN ટ્રાફિકને તે ઝોનમાં જવા દે છે.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

21.02 કરતાં જૂની રિલીઝમાં એ જ ઇન્ટરફેસ લાઇન option ifname તરીકે લખાય છે, તેથી પેસ્ટ કરતા પહેલાં ઇન્સ્ટોલ થયેલ ફર્મવેર કયું સ્વરૂપ સમજે છે તે તપાસો. ફોરવર્ડિંગ સ્ટેન્ઝા એ પરવાનગી છે જે LAN ટ્રાફિકને ટનલનો ઉપયોગ કરવા દે છે. તેના વિના ઉપકરણ ચાલુ હોય છે, ક્લાયન્ટ જોડાયેલો હોય છે, અને કોઈ LAN હોસ્ટ ટનલ સુધી પહોંચતું નથી. રાઉટર ક્લાયન્ટ પર જોડાયેલું પણ ઇન્ટરનેટ નથી એ સૌથી સામાન્ય ફરિયાદ છે.

VPN ઝોન પરનું માસ્કરેડ પેકેટ નીકળતા પહેલાં દરેક LAN સરનામાને રાઉટરના ટનલ સરનામામાં સમેટી લે છે. તેનાથી સામેની બાજુ તમારા સબનેટ સુધીનો રિટર્ન રૂટ બનાવવાની જરૂર રહેતી નથી.

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

NATમાં ખરું અપલિંક નામ આપો

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

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

તે નિયમમાં ppp0 ને ip route અથવા ચાલુ ઇન્ટરફેસ યાદીમાંથી મળતા ઇન્ટરફેસથી બદલો, પછી LAN હોસ્ટ પેજ ખોલે ત્યારે કાઉન્ટર જુઓ. એક જ પ્રદાતાવાળા રાઉટર પર અપલિંક માટે એક માસ્કરેડ નિયમ સામાન્ય રીતે પૂરતો છે. ટનલ ઇન્ટરફેસ માટેનો બીજો નિયમ પહેલાનો વિકલ્પ નથી.

પછી ક્લાયન્ટ વિકલ્પો ઉમેરો જે નક્કી કરે છે કે ટનલમાં શું જાય છે. redirect-gateway નિર્દેશ ક્લાયન્ટનો ઇન્ટરનેટ ટ્રાફિક VPN દ્વારા મોકલે છે, અને તેના વિના ટનલ ફક્ત સર્વર દ્વારા ધકેલાયેલા રૂટ જ વહન કરે છે. DNS ને અડો તે પહેલાં પરિણામી રૂટ કોષ્ટક તપાસો.

બીજા કોષ્ટક સાથે Wi-Fi વિભાજિત કરો

એક રૂટિંગ કોષ્ટક બે ડિફોલ્ટ રાખી શકતું નથી. તેથી જે બીજું SSID ટનલને છોડીને જવું જોઈએ તેને પોતાનું સબનેટ અને પોતાનું કોષ્ટક જોઈએ. ટનલવાળા SSID ને પોતાની રેન્જ આપો, પછી કોષ્ટક પસંદ કરતા નિયમ સાથે ફક્ત તે રેન્જને ટનલમાં રૂટ કરો.

OpenWrt પરના પોલિસી-રૂટિંગ પેકેજો બરાબર એ જ સંયોજન વ્યક્ત કરે છે. હાથે કરવું પણ ચાલે છે — સ્રોત નિયમ અને એવું કોષ્ટક જેનું ડિફોલ્ટ ટનલ ઉપકરણ તરફ ઇશારો કરે.

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

ઘડિયાળ અને ઉપકરણ ફ્લેગ પર શક કરો

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

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