સર્વરનું IP બદલાયા પછી પણ SNAT નિયમ જૂનું જ નામ આપે છે
ટનલ જોડાઈ શકે છે જ્યારે દરેક ફોરવર્ડ થયેલું પેકેટ અટકી જાય છે, કારણ કે અનુવાદનો નિયમ હજી એવા સરનામા પર ફરીથી લખે છે જે હોસ્ટ પાસે હવે નથી.
સર્વર નવા સરનામે ખસી ગયું, ક્લાયન્ટ હજી જોડાય છે, અને તેઓ મોકલે છે તેમાંથી કંઈ પણ ઇન્ટરનેટ સુધી પહોંચતું નથી. એ જ વિભાજન સૂત્ર છે: સાંભળતું સોકેટ અને પોર્ટ ફોરવર્ડિંગ ખસેડવામાં ટકી ગયાં, તેથી ટનલ ઉપર આવે છે, જ્યારે ફોરવર્ડ થયેલા પેકેટ પર લાગુ પડતો સ્રોત અનુવાદ હજી એવું સરનામું નામ આપે છે જે હોસ્ટ પાસે હવે નથી. એ ફરીથી લખાયેલા પેકેટના જવાબ એવી મશીન પર જાય છે જે હવે ત્યાં નથી.
જોડાણ અને ફોરવર્ડિંગ જુદી જુદી જગ્યાએ નિષ્ફળ જાય છે
સ્થાપના ક્લાયન્ટને પહેલેથી ખબર હોય તેવા અંતિમ બિંદુ પર આધાર રાખે છે: જાહેર સરનામું, તેની સામેનું પોર્ટ ફોરવર્ડિંગ અને અંદરનું શ્રોતા. ફોરવર્ડ થયેલો ટ્રાફિક પેકેટ ટનલમાં પ્રવેશ્યા પછી લેવાતા બીજા નિર્ણય પર આધાર રાખે છે, જ્યારે હોસ્ટ પોતાનો સ્રોત ફરીથી લખે છે જેથી જવાબ પાછા ફરવાનો રસ્તો શોધી શકે.
સરનામું બદલવાથી ફક્ત બીજો નિર્ણય તૂટે છે, અને તેથી જ લક્ષણ "જોડાયેલું પણ ઇન્ટરનેટ નથી" તરીકે વંચાય છે. આ એ પણ સમજાવે છે કે ક્લાયન્ટ બાજુની સામાન્ય તપાસો સ્વસ્થ કેમ દેખાય છે: હેન્ડશેક પૂરો થાય છે, ક્લાયન્ટને સરનામું મળે છે, અને સર્વરના ટનલ સરનામે ping પણ જવાબ આપી શકે છે. બીજી બાજુ રહેલી ખામી માટે ક્લાયન્ટ પર કલાકો વેડફાય છે, તેથી જ નિયમોનું કોષ્ટક પહેલું જોવાનું સ્થળ છે.
સંપાદન કરતા પહેલાં નિયમ અને તેના કાઉન્ટર વાંચો
કાઉન્ટર સાથે અનુવાદના નિયમોની યાદી બનાવો અને ગોઠવેલા સ્રોતની સરખામણી હોસ્ટ પાસે ખરેખર રહેલા સરનામાં સાથે કરો. મૃત સરનામે ફરીથી લખાયેલો નિયમ સામાન્ય રીતે અંદર જતા માર્ગે ટ્રાફિક બતાવે છે, કારણ કે પેકેટ તેને પહોંચે છે અને અનુવાદ પામે છે, અને પાછા જતા માર્ગે કંઈ નહીં.
sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show
ત્યાં હોવા જતાં ત્રણ ક્ષેત્રો તપાસો: સ્રોત મેળમાંનું પૂલ, નિયમ કોઈ નામ આપે તો એક્ઝિટ ઇન્ટરફેસ, અને એ બાકાત જે ટનલ-થી-ટનલ ટ્રાફિકને ફરીથી લખાતો અટકાવે છે. એ બાકાત સંપાદન દરમિયાન ગુમાવવી સહેલી છે, અને તે ગુમાવવાથી સાથી વચ્ચેનો ટ્રાફિક કામ કરતો દેખાય છે જ્યારે તેના જવાબ વિચિત્ર માર્ગ લે છે.
જો કાઉન્ટર શૂન્ય પર અટકી જાય, તો પેકેટ ક્યારેય આ નિયમ સુધી પહોંચતું નથી અને સરનામું હાલની સમસ્યા નથી. સાંકળમાં પહેલાંનો સ્પર્ધાત્મક નિયમ શોધો, જે ત્યારે થાય છે જ્યારે કોઈ મૂળને સંપાદિત કરવાને બદલે બદલી ઉમેરે છે. એક મિનિટ પહેલાં નોંધેલા આઉટપુટ સાથે નિયમ નંબરોની સરખામણી કરો. ક્રમ ગોઠવણીનો ભાગ છે, સજાવટની વિગત નથી.
સ્રોત બદલો, અથવા એક પણ નામ આપવાનું બંધ કરો
જ્યારે હોસ્ટ પાસે સ્થિર સરનામું હોય, ત્યારે બીજું ઉમેરવાને બદલે નિયમને તેની જગ્યાએ બદલો. નિયમ નંબર દ્વારા બદલી બાકીની સાંકળ જે ક્રમ પર આધાર રાખે છે તે જાળવી રાખે છે.
sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40
જ્યારે સરનામું ગતિશીલ રીતે ફાળવાય છે, ત્યારે કોઈ સ્રોતનું નામ ન આપો અને કર્નલને એક્ઝિટ ઇન્ટરફેસમાંથી હાલનું પસંદ કરવા દો. એ પ્રકાર સંપાદન વિના આગલી ખસેડવાની પ્રક્રિયા ટકી જાય છે, બદલામાં કયું સરનામું વપરાયું તે છુપાવે છે.
sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE
IPv4 ફોરવર્ડિંગ હજી સંચાલિત ગોઠવણી દ્વારા સક્ષમ છે તેની ખાતરી કરો, પછી વિતરણની પોતાની પદ્ધતિથી નિયમને ચીરસ્થાયી બનાવો. ફક્ત ચાલુ કર્નલમાં કરેલો ફેરફાર આગલા રીબૂટ સાથે પાછો આવે છે, સામાન્ય રીતે એવી જાળવણી વિન્ડોમાં જેને કોઈ ફેરફાર સાથે જોડતું નથી.
બદલી ખોટી કરવાની બે રીતો
પૂલને સર્વરના LAN સરનામાને બદલે તેના ટનલ સરનામે અનુવાદિત કરવાથી જવાબ સીધા ટનલમાં પાછા જાય છે, જ્યાં તેઓ એવા ક્લાયન્ટ તરફ રૂટ થાય છે જેણે ક્યારેય માંગ્યા નહોતા. જોડાણ રૂટિંગ લૂપ જેવી રીતે અટકી જાય છે, કારણ કે તે ખરેખર લૂપ છે.
જૂની ઉપર બીજો અનુવાદ ચઢાવવો એ બીજી ભૂલ છે. પહેલો મળતો નિયમ જીતે છે, તેથી જૂની એન્ટ્રી કાઢી નાખવાય ત્યાં સુધી પેકેટ સંભાળતી રહે છે, અને નવા નિયમના કાઉન્ટર શૂન્ય પર રહે છે જ્યારે બધા બદલીને દોષ આપે છે. કંઈ નવું ઉમેરતા પહેલાં નકલ કાઢી નાખો. પછી યાદી ફરી એક વાર વાંચો અને ખાતરી કરો કે પૂલ સાથે બરાબર એક જ અનુવાદ મળે છે.
જો ટનલ IPv6 પણ વહન કરે, તો બીજા સ્ટેક પર આખી સમીક્ષા પુનરાવર્તિત કરો. અનુવાદ અને રૂટ કરેલા પ્રીફિક્સ વિનાનું IPv6 ડિફોલ્ટ રૂટ પણ એટલી જ શાંતિથી નિષ્ફળ જાય છે, અને ભૂલી જવું સહેલું છે કારણ કે તેની ઉપરનું બધું એકસરખું દેખાય છે.
આવતા સેવાઓને ઊલટો અનુવાદ જોઈએ
VPN ક્લાયન્ટ પરની સેવા જે બહારથી પહોંચી શકાય તેવી હોવી જોઈએ તેને ગંતવ્ય અનુવાદ જોઈએ, સ્રોત અનુવાદ નહીં: જાહેર પોર્ટ પ્રવેશતા પહેલાં ક્લાયન્ટના ટનલ સરનામે ફરીથી લખાય છે. પછી ફોરવર્ડ માર્ગને એ ટ્રાફિકની પરવાનગી આપતો સ્પષ્ટ નિયમ જોઈએ.
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080
ટનલ પોતે વહન કરે છે તે પોર્ટનો ક્યારેય અનુવાદ ન કરો, કારણ કે એ ફરીથી લખવું સેવાને પહોંચી શકાય તેવી રાખતું જોડાણ તોડી નાખે છે. ટનલ પોર્ટને ગંતવ્ય નિયમોથી સંપૂર્ણ બહાર રાખો. પછી બંને છેડેથી ચકાસો: નવા નિયમ પર કાઉન્ટર, ટનલ ઉપકરણ પર ટૂંકું કેપ્ચર, અને જાહેર સરનામું અજમાવતા પહેલાં ટનલની અંદરના સરનામે એક વિનંતી.