રાઉટ થયેલ VPN ક્લાયન્ટ સર્વર સુધી પહોંચે છે પણ LAN હોસ્ટ સુધી નહીં

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

જવાબને અનુસરો, વિનંતીને નહીં

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

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

રિટર્ન રૂટ ત્યાં મૂકો જ્યાં હોસ્ટ જુએ છે

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

શા માટે સોર્સ NAT તેને સુધારતું લાગે છે

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

ક્લાઉડ માર્ગને ત્રણ સેટિંગની જરૂર છે

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

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

તપાસો આ ક્રમમાં કરો

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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