એ L2TP સરનામું IPCP છે, LAN પર DHCP લીઝ નહીં

કનેક્શન આવે છે અને એડેપ્ટર ઓફિસની શ્રેણીમાં સરનામું બતાવે છે, તેથી સ્વાભાવિક તારણ એ છે કે VPN એ તમને LAN સરનામું આપ્યું અને તેથી તમને LAN પર મૂક્યા. એના બંને અર્ધા ભાગ પૂરા સાચા નથી. L2TP PPP સત્ર વહન કરે છે, અને PPP IPCP સાથે આંતરિક IPv4 સરનામાની વાટાઘાટ કરે છે. એ સરનામું બે પક્ષો વચ્ચે સંમત સત્ર પરિમાણ છે, ઓફિસના DHCP સર્વર દ્વારા આપવામાં આવતી લીઝ નહીં, અને તેને રાખવાથી તમે ઓફિસના તાર પર પાડોશી બનતા નથી.

એક કનેક્શનમાં બે સરનામાં

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

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

IPCP બરાબર શું કરે છે

IPCP એ PPP માટે IPv4 નિયંત્રણ પ્રોટોકોલ છે. દરેક પક્ષ પોતાને જોઈતા વિકલ્પો વર્ણવતા Configure-Request સંદેશા મોકલે છે, અને સરનામા વિકલ્પ તેમાંનો એક છે. જે ક્લાયંટ પાસે હજી સરનામું નથી તે સામાન્ય રીતે 0.0.0.0 સાથે પૂછે છે, અને સર્વર Configure-Nak સાથે જવાબ આપે છે જેમાં ક્લાયંટ વાપરે તેવું તેનું ઇચ્છિત સરનામું હોય છે. પછી ક્લાયંટ એ સરનામું માંગે છે, અને સત્ર સ્થાનિક અને દૂરના સરનામા સાથે આવે છે.

એ વિનિમય PPP અને IPCP વિશિષ્ટતાઓમાં દસ્તાવેજીકૃત છે, અને તે એવી વિગત સમજાવે છે જે ભૂલ જેવી લાગે: સરનામું સર્વર પોતાની નીતિમાંથી પસંદ કરે છે, જે પૂલ, પ્રતિ-વપરાશકર્તા સેટિંગ કે પ્રમાણિત ઓળખ સાથે બંધાયેલું સરનામું હોઈ શકે. જ્યારે પૂલ ખતમ થાય, અથવા નીતિ વિનંતી સાથે અથડાય, ત્યારે પ્રમાણીકરણ સફળ થઈ શકે છે જ્યારે સરનામા વાટાઘાટ નિષ્ફળ જાય, અને ક્લાયંટ એવા કનેક્શનની જાણ કરે છે જે ક્યારેય સ્થિર થતું નથી.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

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

LAN તમને જવાબ કેમ આપી શકતું નથી

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

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

પહેલા સત્ર ચકાસો, પછી રૂટ

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

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

ત્રણ તબક્કા અલગ રાખો

પ્રમાણીકરણ, સરનામા વાટાઘાટ અને ફોરવર્ડિંગ જુદી જુદી રીતે નિષ્ફળ જાય છે, અને દરેકનો અલગ માલિક છે. ઓળખપત્રો ઓળખની સમસ્યા છે, IPCP ખતમ થવું સર્વર નીતિની સમસ્યા છે, અને ખૂટતો પરત રૂટ નેટવર્ક ડિઝાઇનની સમસ્યા છે. ત્રણેયને “VPN તૂટેલું છે” તરીકે જણાવવાથી ધીમો ઉકેલ નિશ્ચિત છે.

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