તમારું VPN હોસ્ટ કરતા પહેલાં VPS એ શું મંજૂરી આપવી જોઈએ

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

પ્રોટોકોલને જરૂરી ઇન્ટરફેસની પુષ્ટિ કરો

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

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

પ્રથમ જોડી પર ઇનકાર એટલે TUN ઉપલબ્ધ નથી અને OpenVPN નો ડિફોલ્ટ મોડ શરૂ થઈ શકતો નથી; છેલ્લી લાઇન પર ઇનકાર એટલે WireGuard કર્નલ ઇન્ટરફેસ ગુમ છે. કર્નલનું TUN/TAP દસ્તાવેજીકરણ પ્રથમ ચકાસણી જે ડિવાઇસની કસોટી કરે છે તેનું વર્ણન કરે છે. બંને નિષ્ફળતાઓમાંથી એક પણ VPN પેકેજ ફરી ઇન્સ્ટોલ કરીને સુધારી શકાતી નથી.

યાદ રાખો કે આંતરિક માર્ગને બે માલિકો છે

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

UDP સામાન્ય ભોગ છે: ઘણા પ્લેટફોર્મ ડિફોલ્ટ રીતે TCP ને મંજૂરી આપે છે અને UDP નિયમોને અલગ એન્ટ્રી તરીકે ગણે છે. જો ઇન્સ્ટન્સ પબ્લિક એડ્રેસ રાખવાને બદલે પ્રોવાઇડરના NAT પાછળ બેસે છે, તો પ્રોવાઇડર બાજુ પર પોર્ટ ફોરવર્ડિંગ મેળવવાપાત્ર ત્રીજું કન્ફિગરેશન બની જાય છે.

પરત માર્ગનું આયોજન કરો, ફક્ત બહાર જવાનું નહીં

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6 નો મુદ્દો સ્પષ્ટ રીતે નક્કી કરો

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

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

બાહ્ય ક્લાયન્ટથી તે સાબિત કરો

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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