CGNAT પાછળથી VPN ક્લાયન્ટ પોર્ટ પ્રકાશિત કરો: ચેકલિસ્ટ

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

ખાતરી કરો કે સર્વર બિલકુલ ફોરવર્ડ કરશે

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

ચાલુ કર્નલમાં તેને સેટ કરવું રીબૂટ દરમિયાન સેટ કરવા જેવું નથી. net.ipv4.ip_forward=1 ને /etc/sysctl.d/ હેઠળની ફાઇલમાં લખો, sysctl --system ચલાવો, અને પછી ફાઇલ ઉપાડવામાં આવી છે તેવું માનવાને બદલે મૂલ્ય ફરી વાંચો. જે કન્ટેનર પોતાનું નેટવર્ક નામસ્થાન સંભાળે છે તેને તે જ જગ્યામાં એ જ મૂલ્યની જરૂર છે, ફક્ત હોસ્ટ પર નહીં.

જો વાંચન હજી શૂન્ય છે, તો અહીં થોભો. નીચે કંઈ પણ કામ કરશે નહીં.

કોઈ નિયમ તેનો ઉલ્લેખ કરે તે પહેલાં ટનલનું સરનામું પિન કરો

પૂલ કનેક્શનના ક્રમમાં સરનામાં આપે છે, તેથી આજના લીઝ માટે લખાયેલો નિયમ આવતા અઠવાડિયે શાંતિથી બીજા ક્લાયન્ટ તરફ ઇશારો કરી શકે છે. સરનામાને આગમનના ક્રમ સાથે નહીં, પ્રમાણપત્રની ઓળખ સાથે બાંધો.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

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

બંને દિશામાં અનુવાદ કરો

ડેસ્ટિનેશન અનુવાદ આવતા પેકેટને ક્લાયન્ટ પર મોકલે છે. સોર્સ અનુવાદ એ છે જે ક્લાયન્ટને મૂળ પ્રેષકને બદલે સર્વરને જવાબ આપવા મજબૂર કરે છે, અને તે જ નિયમ છે જે લોકો છોડી દે છે.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

બંને નિયમ iptables -t nat -S વડે ફરી વાંચો અને ખાતરી કરો કે ઇન્ટરફેસનું નામ એ છે જે જાહેર સરનામું ધરાવે છે. જે હોસ્ટ પહેલેથી nftables વડે ફિલ્ટર કરે છે ત્યાં સાધનો મિશ્ર કરવાને બદલે અનુરૂપ સરનામા કુટુંબની nftables NAT ચેનમાં અનુવાદ લખો.

ફિલ્ટર કોષ્ટકને પસાર થવા દો

NAT કોષ્ટકો હેડર ફરી લખે છે; તેઓ પરવાનગી આપતા નથી. ડિફોલ્ટ DROP નીતિ સાથે ફોરવર્ડ થતા પ્રવાહને પોતાની સ્વીકૃતિની જરૂર છે, ઉપરાંત પરત દિશા જે મોટાભાગની નીતિઓ પહેલેથી established,related નિયમથી આવરી લે છે.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

કંઈ ઉમેરતા પહેલાં FORWARD ચેનની નીતિ તપાસો, કારણ કે વહેલા DROPનો ક્રમ નક્કી કરે છે કે તમારો નિયમ ક્યારેય ધ્યાનમાં લેવાય છે કે નહીં. જે હોસ્ટનું ફિલ્ટરિંગ nftablesમાં રહે છે ત્યાં inet કોષ્ટકના forward હૂકમાં સમકક્ષ નિયમ ઉમેરો અને ખાતરી કરો કે આધાર ચેન ખરેખર ફોરવર્ડ થતો ટ્રાફિક જુએ છે અને ફક્ત સ્થાનિક ઇનપુટ નહીં. જો નવા નિયમ પરનું પેકેટ કાઉન્ટર શૂન્ય રહે જ્યારે NAT કાઉન્ટર વધે, તો પેકેટ તમારા નિયમ પહેલાં કાઢી નાખવામાં આવે છે. તે ચેનનો ક્રમ વાંચવાનો સંકેત છે, એ જ નિયમની બીજી નકલ ઉમેરવાનો નહીં.

બહારના નેટવર્કથી તેને સાબિત કરો

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

tcpdump -ni any port 29443
conntrack -L | grep 29443

સર્વર પર અને ક્લાયન્ટ પર એક જ સમયે કેપ્ચર ચલાવો. સર્વરનું કેપ્ચર બતાવે છે કે અનુવાદિત પેકેટ ટનલ તરફ નીકળે છે કે નહીં; ક્લાયન્ટનું કેપ્ચર બતાવે છે કે વિનંતી પહોંચે છે કે નહીં અને જવાબ ક્યાં સંબોધાયેલો છે. conntrack -L માં અનુવાદ એન્ટ્રી સાબિત કરે છે કે નિયમ મેળ ખાધો, અને તેની ગેરહાજરી સાબિત કરે છે કે પેકેટ ક્યારેય NAT ચેન સુધી પહોંચ્યું નથી.

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