યોગ્ય બેસે એવું VPN ક્લાયન્ટ એડ્રેસ પૂલ કેવી રીતે આયોજન કરવું

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

પૂલ ફીલ્ડ પર જ શરૂ કરો, કોઈ પણ ક્લાયન્ટ કનેક્ટ થાય તે પહેલાં

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

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

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

ક્લાયન્ટને ખરેખર મળેલું સરનામું વાંચો

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

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

ip -4 addr show tun0
ip route get 192.168.50.20

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

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

સેવામાંથી જવાબને પાછળની દિશામાં અનુસરો

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

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

બે ક્લાયન્ટ, પછી એક રદ

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

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

એવા ગંતવ્ય સાથે સમાપ્ત કરો જેને નકારવું જોઈએ. જે ક્લાયન્ટ બધું જ પહોંચે છે તેને કનેક્ટ કરવામાં આવ્યો છે, પરીક્ષણ કરવામાં નથી આવ્યો.

ચાર મૂલ્યો એ જ જગ્યાએ લખો જ્યાં આગલું પરિવર્તન તેમને શોધશે

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

તેની સાથે માલિકીની નોંધ રાખો: ટનલ શ્રેણી VPN સર્વરની છે, અને LAN DHCP વ્યાપમાં કરાયેલું આરક્ષણ ટનલની અંદરના ક્લાયન્ટ માટે કંઈપણ આરક્ષિત કરતું નથી. એ એક લાઇન સૌથી સામાન્ય ફરી કામ અટકાવે છે, જ્યાં કોઈ આરક્ષણ ઉમેરે છે અને ધારે છે કે ટનલનું સરનામું તેને અનુસરશે.