તમારો VPN પૂલ LAN નો DHCP રેન્જ નથી: તે કેમ તૂટે છે

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

બે ફાળવનારા, એક સરનામું જગ્યા

LAN નો DHCP સર્વર જાણે છે કે તેણે કયા સરનામાં લીઝ પર આપ્યાં છે અને કયા MAC સરનામે, અને તેમને ARP થી સાચવે છે. VPN સર્વરનો પોતાનો પૂલ છે અને તે લીઝ વિશે કંઈ જાણતું નથી. બંનેમાંથી કોઈ ખોટું નથી; તેમનો પરસ્પર પરિચય ક્યારેય કરાવવામાં આવ્યો નથી.

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

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

રાઉટર VPN સરનામાં કેમ વહેંચતું નથી

DHCP શોધ એ બ્રોડકાસ્ટ છે, અને બ્રોડકાસ્ટ રાઉટેડ સીમા પર અટકે છે. જો ડિઝાઇન ટનલને બ્રિજ ન કરે અથવા અનુરૂપ અધિકાર સાથે DHCP રિલે ન ચલાવે, તો ક્લાયન્ટની વિનંતી ક્યારેય LAN સર્વર સુધી પહોંચતી નથી.

તેથી VPN સર્વર પોતે સરનામું સોંપે છે: સર્વર કન્ફિગરેશનમાં એક પૂલ, WireGuard સેટઅપમાં દરેક પીઅર માટે એક સરનામું, અથવા IKEv2 જમાવટમાં પ્રમાણીકરણ સ્તર જે સરનામું ધકેલે છે. આ પદ્ધતિઓ LAN લીઝ ડેટાબેઝથી સ્વતંત્ર છે, અને તે જ કારણસર તેમને પોતાની રેન્જની જરૂર છે.

એ જ તર્ક સમજાવે છે કે DHCP સ્કોપ બદલવાથી એ VPN ક્લાયન્ટ કેમ ઠીક થતો નથી જેને ક્યારેય સરનામું મળતું નથી. ક્લાયન્ટ LAN સર્વરને પૂછતું નથી, અને સ્કોપમાં કોઈ પણ સંપાદન તેને પૂછવા મજબૂર કરતું નથી.

ઓવરલેપ ધીમા નેટવર્ક તરીકે નહીં, સંઘર્ષ તરીકે દેખાય છે

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

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

રીટર્ન પાથ અલગ સમસ્યા છે

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

કંઈપણ બદલવા પહેલાં પાથને બંને દિશામાં વાંચો. ગેટવે પર પૂછો કે કર્નલ ક્લાયન્ટ સરનામા માટે કઈ ઇન્ટરફેસ વાપરશે; ક્લાયન્ટ પર પૂછો કે તે LAN સરનામા માટે કયો રૂટ વાપરે છે.

આ આદેશો ગેટવે પરનો ફોરવર્ડિંગ નિર્ણય અને ડુપ્લિકેટ ઉજાગર કરતી પડોશી એન્ટ્રીઓ દર્શાવે છે:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

જો પહેલો આદેશ ટનલ ઇન્ટરફેસ સાથે જવાબ આપે, તો રીટર્ન રૂટ અસ્તિત્વમાં છે. જો તે LAN ઇન્ટરફેસ સાથે જવાબ આપે, તો રાઉટર માને છે કે ક્લાયન્ટ વાયર પર છે અને તેના માટે ARP કરવાનો પ્રયાસ કરશે.

બ્રિજ્ડ ડિઝાઇન અસ્તિત્વમાં છે, પણ તે પસંદ કરવી પડે

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

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

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