VPN સબનેટમાં પોર્ટ ફોરવર્ડ પર SNAT લાગુ કરવું જોઈએ?

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

જવાબ કેમ બીજો રસ્તો લે છે

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

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

વિશ્વાસ કરવા જેટલો સાંકડો સ્રોત નિયમ

રાઉટરને તે સ્રોત બનાવો જેના પર દૂરનો હોસ્ટ જવાબ આપે છે. આ ગોઠવણમાં WAN સરનામું 203.0.113.24 છે, LAN 192.168.88.0/24 છે, રાઉટરનું ટનલ સરનામું 172.20.5.1 છે, અને સેવા 172.20.5.40:8443 પર જવાબ આપે છે. નીચેનો નિયમ લક્ષ્ય અનુવાદ પછીના પેકેટ સાથે મેળ ખાય છે, તેથી તે જાહેર સરનામાને બદલે અનુવાદિત સરનામું નામ આપે છે. તેમાં કંઈ પણ ક્લાયન્ટના સરનામા પર આધાર રાખતું નથી, અને તે જ મુદ્દો છે.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

ક્યારે સર્વગ્રાહી માસ્કેરેડ પ્રામાણિક પસંદગી છે

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

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

પ્રકાશિત કરતા પહેલા કાઉન્ટર તપાસો

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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