VPN ગેટવેના પોતાના સરનામા પર LAN સેવા પ્રકાશિત કરો

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

ક્લાયંટના દૃષ્ટિકોણથી શરૂ કરો

આ ઉદાહરણનો ક્લાયંટ VPN પૂલ 10.62.0.0/24માં બેસે છે અને પોર્ટ 8080 પર 10.62.0.1 સાથે જોડાય છે. તે સરનામું ગેટવેનું પોતાનું છે, તેથી પેકેટ બીજા પીઅરને બદલે ગેટવેના કર્નલમાં પહોંચે છે. ગેટવેની પાછળ LAN 172.21.4.0/24 છે. ગેટવે પાસે 172.21.4.10 છે અને જે ઉપકરણ ખરેખર HTTP સેવા આપે છે તે 172.21.4.40 છે.

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

ગંતવ્ય અનુવાદની વ્યાપ્તિ જાણી જોઈને મર્યાદિત કરો

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

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

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

ફોરવર્ડિંગ સીમા સંમત થવા દો

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

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

ઉપકરણે કોઈક રીતે જવાબ આપવો પડશે

અનુવાદ પછી ઉપકરણ 10.62.0.0/24માં સ્રોત જુએ છે. તેનો જવાબ તેના ડિફૉલ્ટ ગેટવે તરફ જાય છે, જે LAN રાઉટર છે, VPN ગેટવે નહીં, સિવાય કે કંઈક તેને બીજું કહે. બે ગોઠવણો આ સુધારે છે અને તે સમાન નથી. ઉપકરણ પર અથવા LAN રાઉટર પરનો રૂટ 10.62.0.0/24ને 172.21.4.10 પર મોકલે છે અને ક્લાયંટ સ્રોત જાળવે છે. મર્યાદિત સ્રોત અનુવાદ તેના બદલે ક્લાયંટને ગેટવેના LAN સરનામા પાછળ છુપાવે છે.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

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

ગેટવેથી જ પરીક્ષણ કરશો નહીં

ગેટવે પર 10.62.0.1 તરફ બનાવેલી વિનંતી OUTPUT શૃંખલામાંથી નીકળે છે, આવતી PREROUTINGમાંથી નહીં. તેની નિષ્ફળતા કે સફળતા ક્લાયંટ તરફના નિયમ વિશે કંઈ કહેતી નથી, અને આ રીતે લોકો નિષ્કર્ષ કાઢે છે કે કામ કરતો નિયમ તૂટેલો છે.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

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