WireGuard ક્લાયન્ટ OpenVPN ક્લાયન્ટ સુધી પહોંચી શકતું નથી?

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

લક્ષણમાં એક સમયે એક જ ભાગ ખૂટે છે

wg1 પર 10.71.0.0/24 નો WireGuard પૂલ અને tun1 પર 10.72.0.0/24 નો OpenVPN પૂલ વાપરે છે, બંને એક જ ગેટવે પર પૂરા થાય છે. પરીક્ષણ હેઠળની વિનંતી 10.71.0.5 થી 10.72.0.30 પર HTTPS સુધી જાય છે. નીચેનું દરેક પગલું એ જ એક પ્રવાહ વિશે છે. દરેક તપાસની નિષ્ફળતાની સહી અલગ છે છતાં વપરાશકર્તા તેમને એકસરખી અનુભવે છે, અને સામાન્ય રીતે એક સમયે ત્રણમાંથી એક જ ખૂટે છે.

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

સ્પોકનું લક્ષ્ય કવરેજ વધારો

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

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

ગેટવે પર સોર્સ માલિકી રાખો

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

AllowedIPs = 10.71.0.5/32

એ એન્ટ્રીને રૂટિંગ સુવિધા નહીં, માલિકીની ઘોષણા તરીકે વાંચો. ક્લાયન્ટે પહોંચવાનું બાકીનું બધું ક્લાયન્ટની લક્ષ્ય યાદીમાં આવે છે, આ peer શું મોકલી શકે તે વિશેના ગેટવેના ખ્યાલમાં નહીં.

OpenVPN બાજુને પરત માર્ગ આપો

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

push "route 10.71.0.0 255.255.255.0"

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

તમે મંજૂર કરવા માંગતા હતા તે એક જ સેવાને મંજૂર કરો

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

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