OpenVPN સાથે જોડાયેલા છો પણ કંઈ લોડ થતું નથી: ક્લાયન્ટથી બહારની તરફ એક પદચાલન

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

ક્લાયન્ટથી શરૂ કરો અને બહારની તરફ જાઓ

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

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

બે કેપ્ચર દર્શાવે છે કે પેકેટ ક્યાં અટકે છે

ક્લાયન્ટથી જાહેર સરનામા પર ping ચાલુ હોય ત્યારે ટનલ ઇન્ટરફેસ પર એક કેપ્ચર અને ઇન્ટરનેટ સુધી પહોંચવાના અપલિંક પર બીજું કેપ્ચર લો. બંને એકસાથે ચલાવો જેથી સમય-છાપ સાથે મળે.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

તે આઉટપુટનું dev ક્ષેત્ર એ નામ છે જે NAT નિયમને પછી જોઈશે, તેથી તે રાખો.

ફોરવર્ડિંગ એ કર્નલનો સ્વિચ અને ફાયરવોલની નીતિ છે

કર્નલે જાતે ફોરવર્ડ કરવા સંમત થવું પડશે. વર્તમાન મૂલ્ય વાંચો, પછી ફક્ત ચાલતા કર્નલમાં લખવાને બદલે સેટિંગ કાયમી કરો:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

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

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

NAT નિયમમાં ખરેખરા એગ્રેસ ઇન્ટરફેસનું નામ આપો

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

ઉત્તમ નિષ્ફળતા એ ગાઇડમાંથી કોપી કરેલો નિયમ છે જે -o eth0 કહે છે એવી મશીન પર જેનું એડેપ્ટર બીજા નામથી ઓળખાય છે. નિયમ કોઈ ચેતવણી વિના ઇન્સ્ટોલ થાય છે, કંઈ સાથે મળતો નથી, અને ક્લાયન્ટને હજી ઇન્ટરનેટ નથી. પૂલ એ જ ભૂલનો બીજો અર્ધો ભાગ છે: જો સર્વર 10.44.0.0/24 આપે અને નિયમ 10.8.0.0/24 આવરે, તો કંઈ ક્યારેય મળશે નહીં.

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS એ પહેલા પાછળની બીજી નિષ્ફળતા છે

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

સર્વરથી રિઝોલ્વર મોકલો જેથી ક્લાયન્ટને ખબર પડે ક્યાં પૂછવું. બે એન્ટ્રી ક્લાયન્ટને વૈકલ્પિક આપે છે જો પહેલી પહોંચે નહીં, અને બંને એવા રિઝોલ્વર હોવા જોઈએ જે ટનલ ખરેખર મંજૂર કરે.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows ક્લાયન્ટ પછી પણ સ્થાનિક રિઝોલ્વર પર પાછા જઈ શકે છે, અને block-outside-dns બરાબર એ અટકાવવા માટે છે, પણ તેની કિંમત એ છે કે ફક્ત સ્થાનિક નેટવર્ક જે નામો રિઝોલ્વ કરી શકે તે ગુમાવવા. systemd-resolved વાપરતા Linux ક્લાયન્ટ ઘણી વાર મોકલેલા રિઝોલ્વરને અવગણે છે જ્યાં સુધી કોઈ સ્ક્રિપ્ટ તેને ઇન્સ્ટોલ ન કરે, તેથી મોકલવાની અવગણના થઈ એમ માનતા પહેલાં ટનલ ઉપકરણ માટે resolvectl status તપાસો.

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