VPN એડેપ્ટર /32 દર્શાવે છે: તેનો અર્થ એક જ ગંતવ્ય નથી

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

દંતકથા: હોસ્ટ માસ્ક એટલે એક જ પહોંચી શકાય તેવો હોસ્ટ

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

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

સરનામું અને રૂટને અલગ ઑબ્જેક્ટ તરીકે વાંચો

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

ip addr show tun0
ip route show
ip route get 10.60.5.10

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

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

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

માસ્ક પહોળું કરવાથી સામાન્ય રીતે વધુ ખરાબ કેમ થાય છે

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

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

જો દૂરના પ્રીફિક્સનો રૂટ ખૂટે છે, તો તેની જોગવાઈ સુધારો. જો તે હાજર હોય અને કનેક્શન હજી પણ નકારાય, તો માસ્ક ક્યારેય નિદાન નહોતું.

જ્યારે રૂટ સાચો હોય અને પ્રવાહ હજી પણ નિષ્ફળ જાય

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

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

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

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