LAN સર્વર પર VPN ક્લાયન્ટ: જવાબો ખોટા માર્ગે કેમ નીકળે છે

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

જવાબ નવું પેકેટ છે, માર્ગનું ઊંધું વળવું નહીં

જવાબ વિનંતી ગઈ તે જ માર્ગે પાછો આવે છે એ વિચાર છોડવો મદદરૂપ છે. રૂટિંગ દરેક પેકેટ માટે, દરેક દિશા માટે, મોકલનાર હોસ્ટ પર નક્કી થાય છે. ટનલની અંદર 10.64.0.23 થી આવેલી વિનંતી કોઈ પરત માર્ગ બનાવતી નથી; જ્યારે હોસ્ટ જવાબ આપે છે, ત્યારે એ જવાબ નવા પેકેટ તરીકે ટેબલ સાથે મેળવવામાં આવે છે અને જે રૂટ જીતે તેમાંથી નીકળે છે.

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

બાકીનું વાંચતી વખતે બે સબનેટ ધ્યાનમાં રાખો. એક VPN સરનામાં પૂલ છે જ્યાંથી દૂરના ક્લાયન્ટ આવે છે, આ ઉદાહરણમાં 10.64.0.0/24. બીજું LAN છે જે ચાલુ રહેવું જોઈએ, 172.16.24.0/24 તેના રાઉટર સાથે 172.16.24.1 પર. ખામી એ છે કે તેમની વચ્ચેનો ટ્રાફિક ડિફોલ્ટ રૂટ દ્વારા નક્કી થાય છે.

કેપ્ચર અને લુકઅપ થી તેને સાબિત કરો

કંઈપણ બદલતા પહેલા, જવાબ કયું ઉપકરણ વાપરશે તેની ખાતરી કરો. લુકઅપ કેપ્ચર કરતાં ઝડપી છે અને પેકેટ બને ત્યારે કર્નલ જે પ્રશ્નનો જવાબ આપશે તે જ પ્રશ્નનો જવાબ આપે છે.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

જવાબ બે ભાગમાં વાંચો. જો તે dev tun0 નામ આપે, તો હોસ્ટ જવાબને એન્કેપ્સ્યુલેટ કરીને પ્રદાતાને આપશે, અને LAN ક્લાયન્ટ તેને કદી જોશે નહીં. જો તે dev eth0 નામ આપે પણ ક્લાયન્ટ હજી સમયસમાપ્તિ પામે, તો રૂટ પહેલેથી જ સાચો છે અને પેકેટ પછી ફેંકવામાં આવે છે, જે બીજી સમસ્યા અને બીજો ઉપાય છે.

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

ટનલને વટાવતો સૌથી સાંકડો રૂટ ઇન્સ્ટોલ કરો

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

બીજા add ને બદલે replace વાપરો, કારણ કે ફરી જોડાનાર ક્લાયન્ટ પોતાની એન્ટ્રી ઇન્સ્ટોલ કરી ચૂક્યો હશે અને બીજું add હાલના રૂટની ભૂલ સાથે નિષ્ફળ જાય છે જે પરવાનગીની સમસ્યા જેવી લાગે છે. Windows હોસ્ટ પર સમકક્ષ route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p છે, જ્યાં -p રીબૂટ દરમિયાન એન્ટ્રી રાખે છે, કારણ કે ટનલ ફરી ઉપર આવે ત્યારે ક્લાયન્ટ ટેબલ ફરી બનાવી શકે છે. આધુનિક Windows હોસ્ટ પર સમર્થિત સમકક્ષ New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore છે, અને જૂનો route આદેશ લિગસી સ્વરૂપે રાખવામાં આવે છે.

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

ફરી જોડાયા પછી જવાબ રાખો

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

સ્ટેટફુલ ફાયરવોલ સાચા રૂટને હરાવી શકે છે. જો કેપ્ચર હવે બતાવે કે જવાબ eth0 માંથી નીકળે છે અને ક્લાયન્ટ હજી સમયસમાપ્તિ પામે છે, તો તપાસો કે હોસ્ટ મોકલતા પહેલા પેકેટ ફેંકી રહ્યું છે કે નહીં. કડક રિવર્સ-પાથ ફિલ્ટરિંગ અને net.ipv4.conf.all.rp_filter ને 1 પર સેટ કરવાથી, જે પેકેટનો સ્રોત જે ઇન્ટરફેસ પરથી આવ્યો તેના પરથી પાછો રૂટ ન થાય તે ફેંકાય છે, અને આ બરાબર એ જ અસમપ્રમણ કિસ્સો છે જે તમે હમણાં બનાવ્યો અને પછી સુધાર્યો, અને conntrack સ્થિતિ ફોરવર્ડ કરેલા પોર્ટ માટે એ જ વાર્તા કહે છે.

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