VPN સરનામું વિરુદ્ધ LAN DHCP ભાડું: ટનલ IP કોણ આપે છે?

ક્લાયન્ટ જોડો અને Wi-Fi આઇકનને બદલે એડેપ્ટર જુઓ. 10.80.0.14 જેવું સરનામું ટનલ પર હોઈ શકે છે જ્યારે ઓફિસ LAN ના કોઈ DHCP સર્વરે એ ભાડું ક્યારેય નોંધ્યું નથી. કઈ પ્રક્રિયાએ નંબર પસંદ કર્યો તે નક્કી કરે છે કે મુશ્કેલીની શોધ ક્યાંથી શરૂ થાય.

ક્લાયન્ટ પર બધું એકસરખું લાગે છે: એક IPv4 સરનામું, એક માસ્ક, ક્યારેક ડિફોલ્ટ ગેટવે. ફરક ત્યારે જ દેખાય છે જ્યારે તમે પૂછો કે એ સરનામા માટે કોણ જવાબ આપે છે અને તેનો રેકોર્ડ કોણ રાખે છે.

ક્લાયન્ટ બાજુથી ટનલ સરનામું વાંચો

જો તમે પહેલી લાઇનને બદલે આખું બ્લોક વાંચો તો Windows ફરક બતાવે છે. ipconfig /all એડેપ્ટર વર્ણન, ભૌતિક સરનામું અને DHCP લાઇન છાપે છે. PPP અથવા IKEv2 ડાયલ-અપ એડેપ્ટર સામાન્ય રીતે DHCP ને નિષ્ક્રિય જણાવે છે, કારણ કે કનેક્શને LAN સર્વરથી ભાડે લેવાને બદલે ડાયલ-અપ વખતે જ તેનું સરનામું વાટાઘાટ કર્યું હતું. DHCP સક્રિય હોય એવું ટનલ એડેપ્ટર અસામાન્ય છે અને તેની અલગ તપાસ યોગ્ય છે.

Linux એ જ માહિતી બે સાધનોમાં વહેંચે છે. ip -4 addr show dev tun0 સરનામું અને પ્રિફિક્સ લંબાઈ આપે છે. nmcli -f IP4 connection show work જાહેર કરે છે કે મૂલ્ય કનેક્શન પ્રોફાઇલમાંથી, લિંક પરના DHCP વિનિમયમાંથી કે ધકેલાયેલા રૂપરેખાંકનમાંથી આવ્યું છે. WireGuard સૌથી સ્પષ્ટ કિસ્સો છે, કારણ કે ઇન્ટરફેસ દેખાતાં wg-quick રૂપરેખાંકન ફાઇલની Address લાઇન લાગુ કરે છે અને જોડાણ સમયે કોઈ પીઅર કંઈ ફાળવતું નથી.

પ્રિફિક્સ પણ કંઈક કહે છે. /32, અથવા 255.255.255.255 નો માસ્ક, એટલે ગેટવે એક હોસ્ટ સરનામા તરફ રૂટ કરવાની અપેક્ષા રાખે છે, જ્યારે પહોળો માસ્ક ટનલ પાછળ ક્યાંક ઓન-લિંક સબનેટ સૂચવે છે.

IKEv2 રૂપરેખાંકન પેલોડ શું વહન કરે છે

આ કામ માટે IKEv2 પાસે સમર્પિત પ્રણાલી છે. RFC 7296, વિભાગ 3.15.1 માં વર્ણવેલ રૂપરેખાંકન પેલોડ INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS અને તેમના IPv6 સમકક્ષો જેવી વિશેષતાઓ વહન કરે છે. ક્લાયન્ટ પસંદગી ન હોય ત્યારે શૂન્ય લંબાઈની કિંમતવાળી વિશેષતા મોકલે છે, અને જવાબ આપનાર ઇચ્છિત કિંમત પાછી આપે છે. એ વિનિમય પહેલેથી જ એન્ક્રિપ્ટ થયેલા IKE_AUTH ની અંદર થાય છે, તેથી કોઈ DHCP પ્રસારણ ક્યારેય ટનલ પાર કરતું નથી.

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

નેટમાસ્ક વિશેષતા વ્યવહારમાં વૈકલ્પિક છે. ઘણી જમાવટ ફક્ત સરનામું પાછું આપે છે અને ક્લાયન્ટને હોસ્ટ રૂટ સ્થાપિત કરવા દે છે, તેથી જ એક જ પૂલ એક ક્લાયન્ટ પર /32 અને બીજા પર /24 જેવો લાગી શકે છે.

જ્યાં LAN DHCP શ્રેણી અને VPN પૂલ ટકરાય છે

મુશ્કેલી ત્યારે શરૂ થાય છે જ્યારે બંને ફાળવનાર એક જ શ્રેણી તરફ ઈશારો કરે. 10.20.30.0/24 માટેનું DHCP સર્વર 10.20.30.128/25 માટે ગોઠવાયેલા VPN પૂલ વિશે કંઈ જાણતું નથી, તેથી ગેટવે એ જ સરનામું દૂરસ્થ ક્લાયન્ટને આપે ત્યારે તેને 10.20.30.140 પ્રિન્ટરને ભાડે આપતું કોઈ રોકતું નથી. ટકરાવ દિવસો સુધી શાંત રહે છે અને પછી વચ્ચે વચ્ચે આવતી નકલ તરીકે બહાર આવે છે.

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

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

સરનામું કઈ પ્રક્રિયાની માલિકીનું છે તે ચકાસો

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

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

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

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