VPN રૂટમાં આગળનો હોપ: ગેટવે શા માટે સ્થાનિક રીતે પહોંચી શકાય તેવો હોવો જોઈએ

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

આ રનબુક સામાન્ય કેસ આવરી લે છે: 192.168.20.0/24 પર લેપટોપ, LAN સરનામું 192.168.20.5 ધરાવતો VPN ગેટવે, અને તે ગેટવે પાછળ 10.70.0.0/24 દૂરનું નેટવર્ક. નીચેની દરેક કમાન્ડ ધારે છે કે તમે લેપટોપ પર છો, જ્યાં સુધી અન્યથા કહેવામાં ન આવે.

બે સરનામાં, એક રૂટ

ઇચ્છિત એન્ટ્રી 10.70.0.0/24 via 192.168.20.5 છે. પ્રીફિક્સ કહે છે કે પેકેટ ક્યાં જાય છે; via સરનામું કહે છે કે તેને ત્યાં કોણ લઈ જાય છે. કર્નલ એવો રૂટ ઇન્સ્ટોલ કરવાનો ઇનકાર કરે છે જેનો ગેટવે તમે નામ આપેલા ઇન્ટરફેસ દ્વારા તે પહોંચી શકતું નથી, અને તે ઇનકાર એ જ આખો મુદ્દો છે: આગળનો હોપ જેને પહોંચી શકાય તેવું બનવા માટે ટનલની જરૂર છે તે ટનલ બનાવતો આગળનો હોપ ન હોઈ શકે.

તેથી પ્રથમ ચકાસણી «ગેટવે ચાલુ છે» નથી, પણ «ગેટવે આ લિંક પર છે». લેપટોપનું પોતાનું સબનેટ, તેની ARP અથવા પડોશી એન્ટ્રી, અને રૂટમાંનું ઇન્ટરફેસ — બધું સહમત હોવું જોઈએ. જે સરનામું ફક્ત 10.70.0.0/24 ની અંદર અસ્તિત્વ ધરાવે છે તે બીજા રૂટનું ગંતવ્ય હોઈ શકે, પણ પ્રથમનું via ક્યારેય નહીં.

આગળનો હોપ ગેટવેને શું કરવા બંધાય છે

લેપટોપ પર રૂટ ઇન્સ્ટોલ કરવો ફક્ત પ્રથમ હેન્ડઑફ નક્કી કરે છે. પછી ગેટવેને પોતાનો માર્ગ જોઈએ: ફોરવર્ડિંગ સક્ષમ, 10.70.0.0/24 માટે ટનલ રૂટ, અને કોઈપણ એક્સેસ પોલિસી જે નક્કી કરે કે કોણ તેનો ઉપયોગ કરી શકે. Linux પર તે net.ipv4.ip_forward=1 અને ટનલ રૂટ છે; તેની સામેની ફાયરવોલને એવો નિયમ જોઈએ જે ફોરવર્ડ થતા પ્રવાહને મંજૂરી આપે.

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

જે હોસ્ટ મોકલે છે તેનાથી લુકઅપ ચકાસો

કર્નલને પૂછો કે તે કયો આગળનો હોપ પસંદ કરશે, અને જવાબમાંનું ઇન્ટરફેસ વાંચો:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

પછી યોગ્ય જગ્યાએથી પરીક્ષણનું પુનરાવર્તન કરો. ગેટવે પર બનાવેલી વિનંતી ગેટવેના પોતાના સ્રોત સરનામાનો ઉપયોગ કરે છે, જે ગુમ થયેલો પરત રૂટ અથવા ફક્ત અમુક સ્રોતોને મંજૂરી આપતી પોલિસી છુપાવી શકે છે. ip-route મેન્યુઅલ ગંતવ્ય, ગેટવે અને onlink ઓવરરાઇડને અલગ પાડે છે, અને ઓવરરાઇડનો ઉપયોગ કરતા પહેલાં તેને સમજવો યોગ્ય છે.

પહોંચવાની ક્ષમતા ખોટી દર્શાવવા onlink નો ઉપયોગ કરશો નહીં

onlink કર્નલને કહે છે કે ગેટવે માટેની પહોંચ ચકાસણી છોડી દે અને તેમ છતાં ત્યાં મોકલે. તે માર્ગ બનાવતું નથી, જે સરનામું ત્યાં નથી તેના માટે ARP ઉકેલતું નથી, અને તમારા Ethernet સેગમેન્ટ પર દૂરના રાઉટરને જવાબ આપવા મજબૂર કરતું નથી. જે ગેટવે જવાબ આપે છે પણ જોડાયેલા સબનેટમાં બેસતા નથી તેમના માટે તે વાજબી છે, અને જે ભૂલ તમે સમજાવી નથી તેને શાંત કરવા માટે વાપરો ત્યારે તે જાળ છે.

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

પોઇન્ટ-ટુ-પોઇન્ટ ટનલ Ethernet નથી

ટનલ ઉપકરણ ARP કરતું નથી અને ઘણી વાર પડોશીઓનું અર્થપૂર્ણ સબનેટ હોતું નથી. તેના રૂટ ઘણી વાર 10.70.0.0/24 dev tun0 જેવા દેખાય છે, કોઈ via વિના, કારણ કે પીઅર જ બીજું એકમાત્ર અંતિમ બિંદુ છે. તે કોષ્ટકમાં LAN-શૈલીનું via નકલ કરવાથી એવો રૂટ બને છે જે કર્નલ કદાચ નકારી કાઢે અથવા, વધુ ખરાબ, એવા સરનામા તરફ નિર્દેશ કરે જેનો પીઅર ક્યારેય જવાબ આપતું નથી.

રનબુકમાં બંને મોડેલ અલગ રાખો: LAN રૂટમાં પહોંચી શકાય તેવો ગેટવે હોય છે, ટનલ રૂટમાં ઇન્ટરફેસ અને પીઅર હોય છે. WireGuard, OpenVPN અને IPsec બધા થોડા અલગ આકાર રજૂ કરે છે, તેથી એક હોસ્ટ પરથી સામાન્યીકરણ કરવાને બદલે તમે ખરેખર વાપરેલો આકાર નોંધો.

ઉમેરો, પુષ્ટિ કરો, પાછું વાળો

આખો ફેરફાર ત્રણ કમાન્ડ અને એક ચકાસણી છે, અને તે એ જ ક્રમમાં લખવો જોઈએ:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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