PiVPN નું હેન્ડશેક કામ કરે છે, પૃષ્ઠો અટકે છે: MASQUERADE તપાસો

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

ક્લાયન્ટ શું પહોંચી શકે અને શું નહીં તેનાથી શરૂ કરો

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

જે ટનલ સરનામું ping નો જવાબ આપે છે જ્યારે જાહેર સાઇટ્સનો સમય પૂરો થાય છે, તે ફોરવર્ડિંગ કે અનુવાદની સમસ્યાની નિશાની છે, તૂટેલા હેન્ડશેકની નહીં. ક્લાયન્ટનું પોતાનું સ્થિતિ પેનલ આ બંનેને અલગ તારવી શકતું નથી, કારણ કે તે ફક્ત જાણે છે કે નિયંત્રણ ચેનલ ઉપર છે. સર્વર પર ટનલ ઇન્ટરફેસ આનાથી તપાસો: ip -br addr show tun0 અને ખાતરી કરો કે ક્લાયન્ટને આપેલું સરનામું તમે ગોઠવેલા પૂલની અંદર પડે છે. જો પૂલ અને ક્લાયન્ટ સરનામું મળતાં ન આવે, તો પહેલા તે સુધારો, કારણ કે નીચેનો દરેક નિયમ પૂલ સાથે મેળ ખાય છે.

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

જે નિયમ નક્કી કરે છે કે પેકેટ બહાર જશે કે નહીં તે વાંચો

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

જીવંત કોષ્ટકની યાદી બનાવો અને ફક્ત MASQUERADE શબ્દ શોધવાને બદલે આઉટ-ઇન્ટરફેસ કૉલમ વાંચો. ફોર્મેટ કરેલી યાદી કરતાં ઉમેરવાના સ્વરૂપનું આઉટપુટ સરખાવવું સહેલું છે:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

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

સાચવેલો નિયમસંગ્રહ સુધારો, ફક્ત ચાલતો નહીં

ફક્ત જીવંત કોષ્ટક સંપાદિત કરવું આગલા રીબૂટ સુધી ટકે છે, જે તમને સમસ્યા ઉકેલાઈ ગઈ હોવાની ખાતરી કરાવવા માટે બરાબર પૂરતું છે. બૂટ પર પાછા આવતા નિયમો એ ફાઇલમાં રહે છે જે ફાયરવોલ સ્થિરતા પેકેજ ફરી લોડ કરે છે. Debian આધારિત Pi ઇમેજમાં તે ફાઇલ સામાન્ય રીતે /etc/iptables/rules.v4.

તેને અડકતા પહેલાં નકલ લો, પછી MASQUERADE લાઇનનું આઉટ-ઇન્ટરફેસ તમે નોંધેલા ઉપકરણથી બદલો, ઉદાહરણ તરીકે -o wlan0 ને બદલે -o eth0. સ્રોત શ્રેણી જેમ છે તેમ રાખો, સિવાય કે તમારો ક્લાયન્ટ પૂલ બદલાયો હોય. ફરી લોડ કરો અને ખાતરી કરો કે નિયમ હવે સાચું ઉપકરણ દર્શાવે છે:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

બે નજીકની સેટિંગ ભૂલવી સહેલી છે. sysctl net.ipv4.ip_forward એ 1 જણાવવું જોઈએ, અને ઉપલા રાઉટરે ખાનગી સ્રોત સરનામાં જાતે ફિલ્ટર કરવાં ન જોઈએ.

નિયમ કાર્યરત થાય તે સાબિત કરો, પછી હજી શું ધીમું છે તે અલગ કરો

કાઉન્ટર એ જ એકમાત્ર પ્રામાણિક પુરાવો છે કે નિયમ મેળ ખાયો. વિગતવાર યાદી ચલાવો, ક્લાયન્ટ પર ડાઉનલોડ શરૂ કરો અને ફરી ચલાવો. તમારા નિયમની બાજુની પેકેટ અને બાઇટ કૉલમ વધવી જોઈએ, અને શૂન્ય પર રહેતો નિયમ હજી મેળ ખાતો નથી. જો કાઉન્ટર હલે છે પણ પૃષ્ઠો હજી નિષ્ફળ જાય છે, તો સ્રોત શ્રેણીની વાસ્તવિક પૂલ સાથે આનાથી સરખામણી કરો grep -n "^server " /etc/openvpn/server.conf. જો તે હલે છે અને પૃષ્ઠો લોડ થાય છે પણ થ્રુપુટ નબળું છે, તો અનુવાદ પૂરો થયો છે અને બાકીની સમસ્યા બીજે છે.

એક જ ક્લાયન્ટથી બે સ્થાનાંતરણની સરખામણી કરો, એક સ્થાનિક નેટવર્કના હોસ્ટ પર અને એક ટનલ દ્વારા તે જ હોસ્ટ પર. બંને કિસ્સામાં ધીમું હોવું Pi ના અપલિંક કે Wi-Fi લિંક તરફ ઇશારો કરે છે, VPN તરફ નહીં. ફક્ત ટનલ દ્વારા ધીમું હોવું MTU અને ફરી પ્રસારણ તરફ ઇશારો કરે છે, જે તમે આનાથી તપાસી શકો છો ip -s link show tun0 કોઈપણ ક્રિપ્ટો સેટિંગ બદલતા પહેલાં.

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