VPN Windows પર સ્થાનિક LAN અવરોધે છે: રૂટ કે ક્લાયન્ટ નીતિ?
Windows પર સ્થાનિક LAN ઍક્સેસ બે અલગ કારણોસર તૂટે છે: ખૂટતો રૂટ, અથવા સબનેટને છોડી દેતી ગેટવે નીતિ. ત્રણ તપાસ કહે છે કઈ.
તમારા પોતાના ડેસ્ક પરનું પ્રિન્ટર, NAS કે ડેવલપમેન્ટ બોક્સ કામનું VPN કનેક્ટ થાય તે ક્ષણે જ જવાબ આપવાનું બંધ કરે છે. ક્યારેક એક રૂટ આદેશ તેને સેકંડોમાં સુધારે છે; ક્યારેક એ જ રૂટ સાચો હોય છે અને પેકેટો તો પણ અદૃશ્ય થાય છે, એટલે કે તમે સમાન લક્ષણવાળી બીજી સમસ્યા જોઈ રહ્યા છો. નિર્ણય ત્રણ પ્રશ્નો પર આવે છે, અને તેમને ખોટા ક્રમમાં પૂછવું એ જ કારણ છે કે લોકો આખી સાંજ રૂટ કાઢીને ફરી ઉમેરવામાં વિતાવે છે.
કોઈપણ આદેશ પહેલાં ત્રણ પ્રશ્નો
પ્રથમ: સ્થાનિક પ્રીફિક્સ માટે એન્ટ્રી છે, અને શું તે ભૌતિક એડેપ્ટર તરફ નિર્દેશ કરે છે? બીજું: કનેક્ટ થતી વખતે ક્લાયન્ટને ગેટવેથી સ્થાનિક નેટવર્કની પરવાનગી કે નકાર મળે છે? ત્રીજું: તમને ફક્ત LAN માટે આઉટબાઉન્ડ ઍક્સેસ જોઈએ છે, અથવા ઇન્ટરનેટ પરની કોઈ વસ્તુએ પણ તમારા મશીન પર ચાલતી સેવા સુધી પહોંચવું જોઈએ?
પ્રથમ પ્રશ્ન રૂટિંગ ખામીને ફિલ્ટરિંગ ખામીથી અલગ પાડે છે. બીજો કહે છે કે રૂટ સુધારણાને બિલકુલ કામ કરવાની પરવાનગી છે કે નહીં. ત્રીજો સુધારણા બદલે છે: રૂટ આઉટબાઉન્ડ ટ્રાફિક સુધારે છે, જ્યારે પહોંચી ન શકાય તેવી ઇનબાઉન્ડ સેવા સામાન્ય રીતે લિસનર બાઇન્ડિંગ અને રિટર્ન-પાથ સમસ્યા હોય છે, જેને રૂટ વધુ બગાડે છે.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
પ્રશ્ન એક: રૂટ, ફિલ્ટર કે નામ
કંઈપણ ઉમેરતા પહેલાં ટેબલ વાંચો. ઇન્ટરફેસ ઇન્ડેક્સ મહત્વનો છે, કારણ કે નીચેનો દરેક રૂટ આદેશ તેના પર જ નિર્ભર છે:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricસીધું જોડાયેલું સબનેટ સામાન્ય રીતે ટનલ ચાલુ હોવા છતાં ઑન-લિંક રૂટ રાખે છે, તેથી એન્ટ્રી અસ્તિત્વમાં હોઈ શકે અને ટ્રાફિક તો પણ નિષ્ફળ જાય. એ સંયોજન રૂટિંગ પછી ચાલતા ફિલ્ટરની સહી છે, અને એ જ કેસ છે જ્યાં વધુ ચોક્કસ બીજો રૂટ કંઈ જ બદલતો નથી.
સરનામા દ્વારા અને નામ દ્વારા અલગથી પરીક્ષણ કરો. જો ping 192.168.1.50 જવાબ આપે અને net view 192.168.1.50 ન આપે, તો રૂટિંગ ટેબલ ક્યારેય સમસ્યા નહોતું: ટનલે રિઝોલ્વર બદલ્યું અને સ્થાનિક નામ હવે ઉકેલાતું નથી. તેના માટે રૂટ ઉમેરવો વ્યર્થ કામ છે.
પ્રશ્ન બે: શું ગેટવે સ્થાનિક LAN ઍક્સેસની પરવાનગી આપે છે?
વ્યાપારી ક્લાયન્ટ ફક્ત રૂટ ઇન્સ્ટોલ કરતું નથી. તેને કનેક્ટ થતી વખતે નીતિ મળે છે, અને તે નીતિમાં સ્પષ્ટ સ્થાનિક નેટવર્ક પરવાનગી હોઈ શકે છે. Cisco IPsec ડિપ્લોયમેન્ટમાં જૂથ નીતિ split-tunneling સેટિંગ અને અલગ સ્થાનિક LAN ઍક્સેસ ફ્લેગ ધરાવે છે; ક્લાયન્ટમાંનું ચેકબોક્સ એ વિનંતી છે જે ગેટવે નકારી શકે છે. AnyConnect માં પ્રોફાઇલ split સમાવેશ અને બાકાત યાદીઓ તથા એ જ પરવાનગી નિયંત્રિત કરે છે. Windows RRAS પર સમકક્ષ પ્રોફાઇલનો ડિફોલ્ટ ગેટવે વિકલ્પ અને સર્વર આપતા સ્થિર રૂટ છે.
જ્યારે ફ્લેગ બંધ હોય, ત્યારે દસ્તાવેજિત વર્તન એ છે કે ક્લાયન્ટ સીધા જોડાયેલા સબનેટ તરફનો ટ્રાફિક અવરોધે છે, જોકે માન્ય, વધુ ચોક્કસ રૂટ અસ્તિત્વમાં હોય. એટલે જ ક્લાયન્ટની માલિકીના ન હોય તેવા રૂટ પણ ઉમેર્યાના સેકંડો પછી અદૃશ્ય થઈ શકે છે: ક્લાયન્ટને જે સ્થિતિ બનાવવાનું કહેવાયું હતું તે ફરી બનાવી રહ્યો છે, તમારી સામે લડી રહ્યો નથી.
ક્લાયન્ટ લોગ કનેક્ટ થતી વખતે નિર્ણય નોંધે છે, અને તેને વાંચવું મશીન પરના કોઈપણ પ્રયોગ કરતાં ઝડપી છે. જો લોગ કહે કે સ્થાનિક ઍક્સેસ અવરોધાયેલી છે, તો થોભો: કોઈ પણ કમાન્ડ-લાઇન સુધારો તેમાંથી બચતો નથી, અને બાકી રહેતા માર્ગો નીતિ પરિવર્તન, ટનલ દ્વારા સ્રોત સુધી પહોંચવું, અથવા ક્લાયન્ટને વર્ચ્યુઅલ મશીનમાં રાખીને હોસ્ટને સ્થાનિક નેટવર્ક પર છોડી દેવા છે.
પ્રશ્ન ત્રણ: તમને કઈ દિશા જોઈએ છે?
નજીકના ઉપકરણ તરફનો આઉટબાઉન્ડ ટ્રાફિક રૂટિંગનો પ્રશ્ન છે. LAN પ્રીફિક્સને સ્થાનિક ગેટવે તરફ એટલા નીચા મેટ્રિક સાથે નિર્દેશ કરો કે ટનલના ડિફોલ્ટ રૂટને હરાવી શકે:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pબીજું સ્વરૂપ એક ઉપકરણને પિન કરે છે, જ્યારે એક સરનામું જ આખી જરૂરિયાત હોય ત્યારે તમને એ જ જોઈએ. netsh સમકક્ષ એ જ નિર્ણય ઇન્ડેક્સને બદલે ઇન્ટરફેસ નામ દ્વારા નોંધે છે:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentજ્યારે સરનામું અને માસ્ક મેળ ખાતા ન હોય ત્યારે રૂટ આદેશો પેરામીટર ખોટું છે સાથે નિષ્ફળ જાય છે, ઉદાહરણ તરીકે /24 માસ્ક સાથેનું હોસ્ટ સરનામું. સબનેટ રૂટ માટે નેટવર્ક સરનામું અને એક હોસ્ટ માટે હોસ્ટ માસ્ક વાપરો.
ઇનબાઉન્ડ અલગ છે. એ જ મશીન પરનું VNC કે SSH સર્વર પહોંચી ન શકાય તેવું બને છે જ્યારે ઇનકમિંગ કનેક્શનના જવાબ VPN ગેટવે થઈને નીકળી જાય અને ક્યારેય પાછા ન ફરે. રૂટને અડકતા પહેલાં સેવા શેના પર સાંભળે છે તે તપાસો:
netstat -ano | findstr :5900એક ચોક્કસ સરનામા સાથે બંધાયેલો લિસનર બીજા ઇન્ટરફેસ પર જવાબ આપશે નહીં. તેને બધા ઇન્ટરફેસ સાથે બાંધવું એ જાણી જોઈને લીધેલો નિર્ણય છે, જે તમે વિશ્વાસ કરો છો તે નેટવર્ક સુધી મર્યાદિત ફાયરવૉલ નિયમ સાથે લેવાય છે. ફક્ત તે પછી જ રૂટ સુધારણા રિટર્ન પાથ પુનઃસ્થાપિત કરે છે.
બંધ બેસતો સૌથી નાનો ફેરફાર લાગુ કરો
બીજું સામાન્ય પગલું IPv4 એડ્વાન્સ્ડ ગુણધર્મોમાં “દૂરસ્થ નેટવર્ક પર ડિફોલ્ટ ગેટવે વાપરો” પરથી ટિક કાઢવાનું છે. તે ઇન્ટરનેટ ટ્રાફિક સ્થાનિક રાખે છે, પણ એકસાથે બે કામ કરે છે: VPN ડિફોલ્ટ માર્ગ રહેતું નથી, અને ક્લાયન્ટ દૂરસ્થ નેટવર્ક માટેના રૂટ મેળવવાનું બંધ કરે છે, multicast સહિત. ટિક કાઢો તો દૂરસ્થ LAN અદૃશ્ય થાય છે, સિવાય કે સર્વર દરેક ક્લાયન્ટને જરૂરી ચોક્કસ દૂરસ્થ પ્રીફિક્સ ધકેલે.
એ અસમપ્રમાણતા કામનો ક્રમ નક્કી કરે છે. જો દૂરસ્થ બાજુ સંપૂર્ણ પહોંચી શકાય તેવી રહેવી જોઈએ, તો સર્વરથી દૂરસ્થ સબનેટ ધકેલો અને સ્થાનિક ડિફોલ્ટને અકબંધ રાખો. જો સર્વર બદલી ન શકો, તો ટનલે આપેલા સરનામા દ્વારા દૂરસ્થ પ્રીફિક્સ પર કાયમી રૂટ ઉમેરો, અને route print વડે તપાસો કે પ્રીફિક્સ VPN ઇન્ટરફેસ તરફ અને ડિફોલ્ટ હજી ભૌતિક ગેટવે તરફ નિર્દેશ કરે છે.
પછી ખાતરી કરો કે સુધારણા ફરી કનેક્ટ થવા પર ટકી રહે છે, કારણ કે બિન-કાયમી રૂટ એડેપ્ટર સાથે મરી જાય છે અને દરેક કનેક્શન પછી ચાલતી સ્ક્રિપ્ટ તેમના માટે પ્રામાણિક જગ્યા છે. એ જ સત્રમાં એક સ્થાનિક ઉપકરણ અને એક દૂરસ્થ સ્રોતનું પરીક્ષણ કરો, ડિસ્કનેક્ટ કરો, ફરી કનેક્ટ કરો અને ફરી પરીક્ષણ કરો. જો રૂટ સાચો દેખાતો હોવા છતાં સ્થાનિક ઉપકરણ હજી નિષ્ફળ જાય, તો પ્રશ્ન બે પર પાછા જાઓ: ક્લાયન્ટ ફિલ્ટર કરી રહ્યો છે, અને જવાબ નીતિ પરિવર્તન છે, બીજો સ્પર્ધાત્મક રૂટ નહીં.