LAN રાઉટર અને VPN ક્લાયન્ટ: બે ઉપકરણો, બે રૂટ કોષ્ટકો

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

કોઈ રૂટને સ્પર્શ કરતા પહેલા બે હોપ દોરો

એક ઉદાહરણરૂપ લેઆઉટ લો: LAN હોસ્ટ 192.168.50.0/24 પર, સામાન્ય રાઉટર 192.168.50.1 પર, એક સમર્પિત ક્લાયન્ટ 192.168.50.15 પર, અને દૂરનું LAN 10.60.0.0/24 પર જે ફક્ત તે ક્લાયન્ટ પાસેના ટનલ દ્વારા જ પહોંચી શકાય છે. બંને ખાનગી શ્રેણીઓમાંથી એક પણ બીજા સાથે ઓવરલેપ થતી નથી, અને ટનલની પોતાની સરનામા યોજના છે.

બંને ખાનગી શ્રેણીઓ મહત્વની છે કારણ કે તેઓ નક્કી કરે છે કે કયું ઉપકરણ જવાબ આપી શકે. દૂરની બાજુ પેકેટને ક્લાયન્ટના ટનલ સરનામેથી આવતું જોશે, અને તેના જવાબે 192.168.50.0/24 સુધી પાછા જવાનો માર્ગ શોધવો પડશે. જો ફક્ત બહાર જતી દિશા ગોઠવાયેલી હોય, તો વિનંતી કામ કરી શકે છે જ્યારે જવાબ અદૃશ્ય થાય છે.

પગલું 1: રાઉટરને ટનલ તરફ નહીં, ક્લાયન્ટ તરફ દિશા આપો

LAN રાઉટર પર, એક ગંતવ્ય રૂટ ઉમેરો જેનો આગળનો હોપ ક્લાયન્ટનું LAN સરનામું છે:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

તે રેકોર્ડ કહે છે “તેને એ મશીનને પહોંચાડો જે ટનલ કરી શકે”. તે ટનલ કેવી રીતે બને છે તે વિશે કંઈ કહેતું નથી, અને તે ક્લાયન્ટના પોતાના રૂટનો વિકલ્પ નથી. મેનેજ્ડ રાઉટર પર સમકક્ષ ઉપકરણના સ્ટેટિક-રૂટ પૃષ્ઠમાં રહે છે; Linux રાઉટર પર તે LAN ધરાવતા ઇન્ટરફેસના રૂપરેખાંકનમાં આવે છે, તમે બંધ કરશો તેવા શેલમાં નહીં.

બીજા આદેશનો જવાબ તપાસો. જો તે ક્લાયન્ટને gateway અને LAN ઇન્ટરફેસને device તરીકે જણાવે, તો પ્રથમ હોપ સાચો છે અને બાકીનું કામ બીજી મશીન પર છે.

પગલું 2: ક્લાયન્ટને ટનલની બાજુએ તેનો પોતાનો રૂટ આપો

ક્લાયન્ટ હવે 10.60.0.0/24 માટે પેકેટ મેળવે છે અને તેના પોતાના કોષ્ટકમાં જુએ છે. જો તેના ટનલ રૂપરેખાંકને તે પ્રીફિક્સ માટે રૂટ સ્થાપિત કર્યો હોય, તો પેકેટ એન્ક્રિપ્ટેડ રહીને આગળ વધે છે. જો ન કર્યું હોય, તો પેકેટ સામાન્ય ડિફોલ્ટ સાથે મેળ ખાય છે અને 192.168.50.1 પર પાછું જાય છે, જે તેને ફરીથી ક્લાયન્ટ પર મોકલે છે.

કંઈ ઉમેરવા પહેલા જુઓ:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

દરેક કોષ્ટકમાં પ્રીફિક્સ રૂટનો અભાવ એ જ શોધ છે જે તમે શોધી રહ્યા છો. તેને ટનલના પોતાના રૂપરેખાંકન દ્વારા ઉમેરો, જેથી આગલું પુનઃકનેક્શન તેને ફરીથી સ્થાપિત કરે; હાથે કરેલું ip route add સત્ર સાથે અદૃશ્ય થાય છે અને સૌથી અયોગ્ય સમયે ખામી પાછી લાવે છે. આગળનો હોપ ટનલ ઇન્ટરફેસ છે અથવા તે સરનામું છે જે VPN તેના પીઅર તરીકે આપે છે, ક્લાયન્ટ પર આધારિત, અને પીઅર સરનામું જૂની નોંધમાંથી નહીં, વર્તમાન પ્રોફાઇલમાંથી આવવું જોઈએ.

લૂપ, જ્યારે થાય છે, ત્યારે વ્યવહારમાં અનંત નથી: દરેક પાસ પર TTL ઘટે છે અને પેકેટ સમય વીતી ગયાના સંદેશ સાથે મરે છે. તેથી પુનરાવર્તિત traceroute ચક્ર સૂચવી શકે છે જ્યારે ફક્ત ફોરવર્ડ ન કરતું ક્લાયન્ટ એ જ પેકેટ શાંતિથી પડતું મૂકે છે.

પગલું 3: ફોરવર્ડિંગને મંજૂરી આપો અને પરત માર્ગ પસંદ કરો

મેળવવું અને ફોરવર્ડ કરવું અલગ પરવાનગીઓ છે. ક્લાયન્ટ પર net.ipv4.ip_forward=1 કર્નલ સ્તરે ટ્રાન્ઝિટની મંજૂરી આપે છે, અને ફાયરવોલ નિયમે હજી પણ તેને LAN ઇન્ટરફેસ અને ટનલ વચ્ચે મંજૂર કરવો પડે છે. જે નિયમ ક્લાયન્ટના પોતાના મેનેજમેન્ટ પૃષ્ઠની ઍક્સેસ મંજૂર કરે છે તે દૂરના LAN તરફ ટ્રાન્ઝિટ મંજૂર કરશે નહીં, અને જ્યારે એ જ હોસ્ટ સ્થાનિક રીતે pingનો જવાબ આપે છે ત્યારે આ ભેદ ચૂકી જવો સહેલો છે.

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

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

પગલું 4: બંને નિર્ણયોને ચાલુ રાખો, પછી વાસ્તવિક માર્ગનું પરીક્ષણ કરો

દરેક રૂટનો માલિક હોય છે, અને માલિક એ રૂપરેખાંકન છે જે બૂટ પર અથવા પુનઃકનેક્શન પર ફરીથી બને છે. રાઉટર પર તે સ્ટેટિક રૂટ એન્ટ્રી હોઈ શકે; ક્લાયન્ટ પર તે VPN પ્રોફાઇલ, NetworkManager અથવા systemd-networkd હોઈ શકે. ટનલ ફરીથી જોડીને અને ક્લાયન્ટ રીબૂટ કરીને ચકાસો, પછી ફેરફાર પર ભરોસો મૂકવાને બદલે કોષ્ટક ફરીથી વાંચો.

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

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