LAN યજમાન OpenVPN ક્લાયન્ટના સરનામા માટે ARP કેમ મોકલે છે

LAN યજમાન અને VPN ક્લાયન્ટ વચ્ચેની પહોંચની સમસ્યાઓ ઘણી વાર સરનામાંની યોજના તરફ જ પાછી આવે છે. તે યજમાનને 10.0.100.0/22 પર ઇન્ટરફેસ આપો અને તે 10.0.100.0 થી 10.0.103.255 સુધીના દરેક સરનામાને સીધું જોડાયેલું ગણશે, જેમાં 10.0.101.0/24 પર શાંતિથી મૂકાયેલ ક્લાયન્ટ પૂલ પણ સમાવિષ્ટ છે. જવાબ કદી રાઉટર પાસે જતો નથી, કારણ કે યજમાનના દૃષ્ટિકોણથી કોઈ રાઉટર સંકળાયેલું નથી. પેકેટ પાડોશીને સંબોધિત છે અને તાર પર માંગવામાં આવે છે.

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

એ /22 જે /24ને ગળી જાય છે

પ્રીફિક્સને શ્રેણી તરીકે વાંચો, સ્ટ્રિંગ તરીકે નહીં. /22માં 1024 સરનામાં હોય છે, અને 10.0.100.0/22 10.0.100.0 થી 10.0.103.255 સુધી ફેલાયેલું છે, તેથી 10.0.101.0/24નો પૂલ સંપૂર્ણપણે તેની અંદર છે. આ ભૂલ સમીક્ષામાંથી બચી જાય છે કારણ કે પૂલના પહેલા ઓક્ટેટ LANના પહેલા ઓક્ટેટથી અલગ દેખાય છે, અને ફક્ત ત્રીજો ઓક્ટેટ આ સમાવેશ જાહેર કરે છે. બંને શ્રેણીઓ અંકોમાં લખો, તેમને અલગ જાહેર કરતાં પહેલાં.

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

સીધું જોડાણ એટલે ARP, રાઉટિંગ નહીં

/22 ઇન્ટરફેસવાળું યજમાન જ્યારે 10.0.101.25 પર મોકલે છે, કર્નલ ગંતવ્યની તુલના ઇન્ટરફેસના પ્રીફિક્સ સાથે કરે છે અને મેળ મેળવે છે. પેકેટ રાઉટ થયેલા પેકેટની જગ્યાએ પાડોશી શોધ બની જાય છે, અને ઇથરનેટ પર પાડોશી શોધ તે સરનામા માટે ARP વિનંતી છે. જો સરનામું રાઉટેડ ગેટવે પાછળના VPN ક્લાયન્ટનું હોય, તો LAN પર કોઈ યજમાન તેનો માલિક નથી, તેથી વિનંતી જવાબ વગર રહે છે અને પેકેટ ફેંકી દેવાય છે. ટનલ દોષિત નથી, અને ક્લાયન્ટ ટ્રાફિક કદી જોતું નથી.

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

TUN, TAP અને દરેક શું વહન કરે છે

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

નિષ્કર્ષ કાઢતાં પહેલાં નોંધો કે ARP વિનંતી ક્યાં દેખાઈ અને કઈ સિસ્ટમે મોકલી. મોકલનાર તમને કહે છે કે તે ગંતવ્ય વિશે શું વિચારે છે, ટનલ શું કરે છે તે નહીં.

એવો પૂલ ડિઝાઇન કરો જે ઓવરલેપ ન થઈ શકે

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

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

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