VPN ક્લાયન્ટ્સ જોડાય છે પણ ઇન્ટરનેટ નથી: ત્રણ ખૂટતા ભાગ

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

કાર્યરત ટનલ પાસે હજી બહાર જવાનો રસ્તો કેમ નથી

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

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

તેથી ક્લાયન્ટને બદલે ત્રણ સ્તરોની કસોટી કરો, અને પરિણામનો અર્થ થાય તે માટે એક વખતે એક જ બદલો.

ફોરવર્ડિંગ એ કર્નલ સ્વિચ છે જેને ટકાવવો પડે

બદલતા પહેલાં વર્તમાન મૂલ્ય તપાસો, પછી તેને સેટ કરો અને ખાતરી કરો કે ફેરફાર અમલમાં આવ્યો.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

તેને /etc/sysctl.d/ હેઠળની ફાઇલમાં કાયમી બનાવો, પછી જાણવા માટે રીબૂટ કરવાને બદલે તે ફાઇલ લાગુ કરો. FreeBSD માં સમકક્ષ net.inet.ip.forwarding છે, અને ટકાઉપણા માટે rc.conf માં gateway_enable=YES. જે ઉપકરણ ફોરવર્ડિંગ બંધ હોવાનું જણાવે છે તે «પેકેટ આવે છે અને કંઈ પાછું આવતું નથી» એવા આખા વર્ગના અહેવાલો સમજાવે છે. દરેક અપગ્રેડ પછી પણ સેટિંગ તપાસો, કારણ કે ફરી બનાવેલ કર્નલ અથવા બદલાયેલ ઉપકરણ ઇમેજ કોઈને કહ્યા વગર તેને રીસેટ કરી શકે છે.

masquerade અથવા એક નિશ્ચિત અનુવાદ સરનામું પસંદ કરો

ગતિશીલ બહારના સરનામા સાથે masquerading સૌથી સરળ સાચું સ્વરૂપ છે. ટનલ સબનેટને સ્રોત અને બહારના ઇન્ટરફેસને નિકાસ તરીકે ઓળખાવો.

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

સ્થિર જાહેર સરનામા સાથે સ્રોતનો અનુવાદ બરાબર તે જ સરનામા પર વધુ અનુમાનિત અને ઓડિટ કરવા સરળ છે.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

ફિલ્ટર કોષ્ટક ત્રીજું દરવાજો છે

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

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

પૃષ્ઠ ક્યારેય લોડ ન થાય ત્યારે ક્યાં જોવું

ટનલ છે તે સાબિત કરવા સર્વરના ટનલ સરનામા પર ping કરો. પછી ક્લાયન્ટથી જાહેર સરનામા સુધી traceroute ચલાવો અને વાંચો ક્યાં થંભે છે: સર્વર પર પેકેટ પહોંચે છે પણ ફોરવર્ડ કે અનુવાદ થતું નથી; સર્વરની પાર સમસ્યા ઉપરની બાજુ છે અને તમારા હાથની બહાર.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

સર્વર પર, ક્લાયન્ટ પૃષ્ઠ લોડ કરે ત્યારે બહારના ઇન્ટરફેસને જુઓ. ખાનગી સ્રોત સરનામા સાથે નીકળતો ટ્રાફિક એટલે અનુવાદ ખૂટે છે, અને જવાબ જ ન આવે એટલે ફોરવર્ડ માર્ગ કે ઉપરનો પાછો માર્ગ તેને પડવા દે છે.

જો દૂરના ક્લાયન્ટ્સને સર્વરના LAN ના હોસ્ટ સુધી પણ પહોંચવું હોય, તો યાદ રાખો કે LAN ને ટનલ સબનેટ સુધી પાછા માર્ગની જરૂર છે. આ અનુવાદ નહીં, રૂટિંગ છે, અને ઇન્ટરનેટ માર્ગ અંતે કામ કર્યા પછી સૌથી વધુ ભૂલાતું પગલું આ જ છે.