VPN પોર્ટ ખોલવાથી ક્લાયન્ટ્સ LAN સુધી પહોંચતા નથી

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

બે શૃંખલા, બે જુદા લક્ષ્ય

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

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

શ્રોતા નિયમ ખરેખર શું મંજૂરી આપે છે

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

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

ક્લાયન્ટથી ચકાસો, ગેટવેથી ક્યારેય નહીં

ગેટવે પર બનાવેલી ચકાસણી હોસ્ટના પોતાના આઉટપુટ માર્ગને અનુસરે છે અને ફોરવર્ડ માર્ગ બંધ હોવા છતાં સફળ થઈ શકે છે. ચકાસણી ક્લાયન્ટથી શરૂ કરો અને પ્રવાહના બંને છેડા જુઓ.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

ફોરવર્ડિંગને એક નહીં, ત્રણ વસ્તુઓ જોઈએ

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

દસ્તાવેજીકરણમાં બંને નિયમ સમૂહો અલગ રાખો

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

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

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