VPN ક્લાયન્ટ સર્વર સુધી પહોંચે છે, LAN સુધી નહીં: કયો ઉપાય?

ક્લાયન્ટ OpenVPN સર્વરના ટનલ સરનામાંને ping કરે છે અને જવાબ મેળવે છે, પછી સર્વરના LAN પર હોસ્ટ અજમાવે છે અને કંઈ મળતું નથી. આ વિભાજન ખામીને ઘણું મર્યાદિત કરે છે: ટનલ ચાલુ છે, ફોરવર્ડિંગ કદાચ કામ કરે છે, અને જવાબ એવા દરવાજેથી નીકળે છે જે પાછો ન લઈ જાય. ત્રણ ઉપાય છે, અને સાચો તમે શું નિયંત્રિત કરો છો અને શું છોડવા તૈયાર છો તેના પર આધારિત છે. નીચેના ત્રણ પ્રશ્નોના ક્રમમાં જવાબ આપો અને પસંદગી સ્વાદની બાબત નહીં રહે.

પહેલાં નક્કી કરો કે કઈ દિશા તૂટી છે

વિનંતી VPN પૂલમાંથી આવેલા સ્રોત સરનામા સાથે ટનલ ઇન્ટરફેસ પર આવે છે. સર્વર તેને LANના હોસ્ટ સુધી મોકલે છે, અને તે હોસ્ટ પોતાના કોષ્ટકે નામ આપેલા ગેટવેને જવાબ આપે છે, સામાન્ય રીતે LANના રાઉટરને. રાઉટર પાસે પૂલ માટે રૂટ ન હોય તો જવાબ ત્યાં જ મરે છે અથવા ઇન્ટરનેટ તરફ ભટકે છે.

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

જો LANનો હોસ્ટ પહેલેથી VPN સર્વર તરફ ઇશારો કરતો હોય, તો તમારી સમસ્યા ફાયરવોલ નિયમ કે MTU મર્યાદા છે, પાછા જવાનો રસ્તો ખોવાયો નથી. ફિલ્ટર સુધારવા રૂટ ઉમેરશો નહીં.

પહેલો પ્રશ્ન: શું તમે દૂરના LANનું રાઉટર સંપાદિત કરી શકો છો?

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

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

જે NAS કે Layer 3 સ્વિચ સેવા હોસ્ટ કરે છે તેને પણ એ જ રૂટ જોઈએ, સિવાય કે તે બધું એવા રાઉટર દ્વારા મોકલે જેની પાસે તે હોય. જે ઉપકરણ સબનેટ સમાપ્ત કરે છે તેની તપાસ કરો, ફક્ત ઇન્ટરનેટ તરફ જોતું નહીં. નાના નેટવર્કમાં ઘણી વાર રૂટિંગ વિશે મત ધરાવતાં ત્રણ ઉપકરણો હોય છે.

બીજો પ્રશ્ન: શું LAN ક્લાયન્ટ સરનામાં જોવાનું બંધ કરી શકે?

જ્યારે રાઉટર બીજા કોઈનું હોય, ત્યારે VPN સર્વર પર અનુવાદને સહકારની જરૂર નથી. LANનો હોસ્ટ સર્વરનું LAN સરનામું જુએ છે, તેને જવાબ આપે છે, અને સર્વર પાછું અનુવાદ કરે છે. તેથી જ ઉપકરણો અને NAT આધારિત દૂરસ્થ પ્રવેશ ભૂમિકાઓ આવું વર્તન કરે છે.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

કિંમત શ્રેય છે: પ્રતિ ક્લાયન્ટ સરનામાં LANના લોગમાંથી અદૃશ્ય થાય છે. LANના હોસ્ટ પરની કોઈપણ પરવાનગી સૂચિ પછી પૂલને બદલે સર્વરનું નામ લેશે.

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

ત્રીજો પ્રશ્ન: શું સર્વર પોતે બીજી ટનલનું ક્લાયન્ટ છે?

બીજી ટોપોલોજી કલ્પો: VPN સર્વર વ્યાપારી પ્રદાતાને પણ ડાયલ કરે છે, તેથી તેની બે ટનલ અને સરનામાંના બે સેટ છે. પોતાના ક્લાયન્ટ માટે મોકલાતો ટ્રાફિક પ્રદાતામાંથી બહાર જાય છે, અને તે જવાબોને પૂલ સરનામાં તરફ પાછા રૂટ કરશે નહીં. તેથી જ બંને ટનલ સ્વસ્થ હોવા છતાં જવાબો અદૃશ્ય થાય છે.

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

પછી બંને દિશાઓ અને બંને માપ ચકાસો

બદલાવ પછી ક્લાયન્ટથી LANના હોસ્ટ સુધી અને પછી LANના હોસ્ટથી ક્લાયન્ટ સુધી ping કરો. બીજી દિશા એ જ છે જે લોકો છોડી દે છે, અને તે જ અધૂરા અનુવાદ નિયમને ઉઘાડું કરે છે. બંને પરિણામ સમય-છાપ સાથે નોંધો જેથી પછીનું પુનઃપતન તુલનાત્મક હોય.

પછી સાચો ડેટા ખસેડો, કારણ કે નાનું ping સફળ થાય જ્યારે મોટું સ્થાનાંતરણ અટકી જાય તે MTUનું લક્ષણ છે. તે ખામી રૂટ સુધારવા બદલ તમે જાતને અભિનંદન આપો તે તરત જ દેખાય છે.

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