SNAT, DNAT અને Masquerade: દરેક VPN NAT નિયમ શું કરે છે

VPN ગેટવેની બંને બાજુ કેપ્ચર મૂકો અને એક ફ્લો ચાર જુદા સરનામાં દર્શાવી શકે છે. સ્રોત NAT ફરીથી લખે છે કે પેકેટ ક્યાંથી આવે છે તેમ કહે છે; ગંતવ્ય NAT ફરીથી લખે છે કે તે ક્યાં જાય છે. Masquerade ત્રીજી દિશા નથી, તે એક સ્રોત-NAT નિયમ છે જે નિશ્ચિત મૂલ્યને બદલે બહાર જતા ઇન્ટરફેસનું સરનામું લે છે. ત્રણમાંથી તમને ખરેખર કયું જોઈએ તે નામ આપો અને મોટાભાગની «VPN તૂટેલું છે» ટિકિટ પરત માર્ગ વિશેના પ્રશ્નમાં ફેરવાઈ જશે.

દરેક નિયમ શું ફરી લખે છે

સ્રોત NAT, સામાન્ય રીતે SNAT લખાય છે, રાઉટર અથવા ગેટવે છોડતી વખતે ફ્લોનું સ્રોત સરનામું બદલે છે. સ્વીકારતી સેવા અનુવાદિત સરનામા પર જવાબ આપે છે, અને અનુવાદ કરતું બોક્સ તે કનેક્શન માટે રાખેલી સ્થિતિ વડે ફેરફાર ઉલટાવે છે. Linux માં એ સ્થિતિ conntrack માં રહે છે, તેથી conntrack -L મૂળ અને જવાબ ટ્યુપલ બાજુમાં છાપે છે.

ગંતવ્ય NAT, DNAT, તેના બદલે ગંતવ્ય બદલે છે. UDP 51820 પર જાહેર સરનામા પર મોકલેલ પેકેટને 10.8.0.2:51820 પરના આંતરિક WireGuard સર્વર પર ફરી લખી શકાય છે. ઘરના રાઉટર અથવા ક્લાઉડ લોડ બેલેન્સર આ રીતે VPN શ્રોતા પ્રકાશિત કરે છે, અને તે ટનલ પછી શું વહન કરી શકે તે વિશે કંઈ કહેતું નથી.

Masquerade SNAT પરિવારનું છે. નિયમ કોઈ સરનામું નામ આપતો નથી; પેકેટ નીકળતી વખતે બહાર જતા ઇન્ટરફેસ પાસે જે સરનામું હોય તે વાપરે છે. Linux તેને પોતાનું લક્ષ્ય આપે છે, અને DHCP કે PPPoE થી સરનામું મેળવતા WAN ઇન્ટરફેસ પર તે સામાન્ય પસંદગી છે.

મેપિંગ ક્યાં રહે છે તે નિષ્ફળતા નક્કી કરે છે

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

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

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

Masquerade કે સ્પષ્ટ SNAT

બંનેને તેમનાં વચનો પ્રમાણે સરખાવો. Masquerade એગ્રેસ સરનામું પસંદ કરે છે, સ્પષ્ટ SNAT તેને પિન કરે છે. સ્થિર જાહેર સરનામા ધરાવતા ગેટવે પર પિનિંગ લોગ અને ભાગીદાર મંજૂરી-યાદીને એક અનુમાનિત મૂલ્ય આપે છે. ગતિશીલ WAN લિંક પર પિન કરેલું SNAT સરનામું લીઝ બદલાતાં જ ખોટું થાય છે, અને Masquerade બરાબર એ જ કેસ માટે બનાવાયું છે.

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

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

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

Linux ગેટવે પર નિયમો વાંચવા

10.8.0.0/24 પર ક્લાયન્ટ અને eth0 નામનું WAN ઇન્ટરફેસ ધરાવતા રિમોટ-એક્સેસ ગેટવેને ફોરવર્ડિંગ ચાલુ અને ફ્લોને મંજૂરી આપતી ફિલ્ટર પોલિસી જોઈએ, પછી જ કોઈ NAT નિયમ મદદ કરી શકે. iptables સંસ્કરણ બંને દિશા nat ટેબલમાં રાખે છે:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables સ્વરૂપ એ જ બે હૂક નામવાળા ઇન્ટરફેસ અને સ્પષ્ટ ચેન સાથે વાપરે છે:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

બંને સ્નિપેટ ધારે છે કે ફિલ્ટર ચેન પહેલેથી ફોરવર્ડ થયેલા ફ્લોને સ્વીકારે છે. NAT મંજૂરીનો નિયમ નથી, અને યોગ્ય રીતે અનુવાદિત પેકેટ પણ એક ટેબલ પછી ફેંકાઈ શકે છે. conntrack -L વડે જીવંત મેપિંગની પુષ્ટિ કરો, nft list ruleset કે iptables-save -t nat વડે શું લોડ થયું તેની પુષ્ટિ કરો, પછી સરનામું ખરેખર બદલાય છે તે જોવા બંને ઇન્ટરફેસ પર કેપ્ચર કરો.

ખરાબ નિયમ જેવા દેખાતા નિષ્ફળતાના પ્રકારો

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

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

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

નિયમ સાચવતાં પહેલાંની ચેકલિસ્ટ

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

ગેટવેથી નહીં, ક્લાયન્ટથી પરીક્ષણ કરો. ગેટવે પરનું બ્રાઉઝર ક્લાયન્ટ અનુવાદ નિયમને સંપૂર્ણપણે ટાળી શકે છે, તેથી ત્યાં ચાલતું પૃષ્ઠ ટનલ વિશે કંઈ સાબિત કરતું નથી. ક્લાયન્ટમાંથી ઉદ્દભવેલી એક વિનંતી મોકલો, કાઉન્ટર અને conntrack ટેબલ જુઓ, અને જ્યાં તમે કામ કરો છો ત્યાં તેમાંથી કોઈપણ શક્ય હોય તો ટનલ ફરી જોડાયા અને WAN સરનામું બદલાયા પછી તેને પુનરાવર્તિત કરો.