NAT પાછળના WireGuard પીઅર પર પોર્ટ ફોરવર્ડિંગ: DNAT અને SNAT

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

એક વિનંતીને શરૂઆતથી અંત સુધી અનુસરો

વિનંતી પ્રોક્સીના જાહેર ઇન્ટરફેસ પર પહોંચે છે, સ્રોતમાં ક્લાયન્ટનું જાહેર સરનામું અને લક્ષ્યમાં પ્રોક્સીનું સરનામું હોય છે. nat PREROUTING માં DNAT નિયમ લક્ષ્યને પીઅરના ટનલ સરનામા 10.90.0.2 પર ફરીથી લખે છે. પછી રૂટિંગ નિર્ણય પેકેટને wg0 દ્વારા બહાર મોકલે છે, અને ફોરવર્ડ માર્ગ પૂર્ણ થાય છે.

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

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

પરત અનુવાદ ઉમેરો

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

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

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

ટનલ જ્યાં છે ત્યાં નિયમો મૂકો

ટનલ સરનામા કે ઇન્ટરફેસનો ઉલ્લેખ કરતા નિયમો wg-quick દ્વારા તે કન્ફિગર થયા પછી ચાલવા જોઈએ. ઇન્ટરફેસ PreUp પહેલાં બને છે, પણ સરનામાં, MTU, DNS અને રૂટ પછી લાગુ થાય છે, અને તે બધું જગ્યાએ હોય ત્યારે PostUp ચાલે છે. ઉમેરાઓ PostUp માં અને દૂર કરવા PreDown માં મૂકો.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

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

પરિણામ iptables -t nat -S વડે ફરી-જોડાણ પછી તપાસો. જો એ જ નિયમ બે વાર દેખાય, તો PreDown લાઇન મેળ ખાતી નથી અને સફાઈ ચૂપચાપ નિષ્ફળ જાય છે.

ફોરવર્ડિંગ, ફિલ્ટરિંગ અને બીજું NAT

IPv4 ફોરવર્ડિંગ કાયમી રૂપે સક્ષમ કરો, પછી ફિલ્ટર કોષ્ટકમાં ફોરવર્ડ થયેલા પ્રવાહને મંજૂરી આપો. DNAT FORWARD શૃંખલા પહેલાં થાય છે, તેથી ફિલ્ટર નિયમ જાહેર સરનામા સાથે નહીં પણ અનુવાદિત લક્ષ્ય સાથે મેળ ખાય છે. જો UFW ફાયરવોલ સંભાળે છે, તો મંજૂરીને રૂટ નિયમ તરીકે વ્યક્ત કરો; સાદો હોસ્ટ નિયમ ફોરવર્ડ થયેલા ટ્રાફિકને આવરી લેતો નથી.

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

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

પરત માર્ગ ચકાસો અને ખર્ચ સ્વીકારો

પ્રોક્સીનું LAN ન હોય તેવા નેટવર્કથી કનેક્ટ કરો, પછી કનેક્શન ખુલ્લું હોય ત્યારે અનુવાદ જોડીની તપાસ કરો:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

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

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

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