VPN ક્લાયન્ટની સેવા સુધી પહોંચવું: રિવર્સ ટનલ કે DNAT

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

બે આકાર, એક મિલનસ્થળ

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

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

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

બંનેમાંથી કોઈ પણ આકાર રચનાથી વધુ સુરક્ષિત નથી. બંને એક સેવા પોર્ટને એવા દરેકને ખુલ્લો કરે છે જે સર્વરના જાહેર સરનામા સુધી પહોંચી શકે, અને બંને હજી પણ સેવાના પોતાના પ્રમાણીકરણ પર આધાર રાખે છે.

શરત એક: શું પોર્ટ સેશન કરતાં વધુ જીવવો જોઈએ

રિવર્સ ફોરવર્ડિંગ તેને બનાવનાર SSH સેશન જેટલું જ જીવે છે. જ્યારે લિંક તૂટે છે, સાંભળનાર અદૃશ્ય થઈ જાય છે અને સહકર્મી ધીમા માર્ગને બદલે નકારેલું કનેક્શન જુએ છે. systemd યુનિટ અને રિસ્ટાર્ટ નીતિ સાથે આદેશની દેખરેખ તેને સુધારે છે, અને ExitOnForwardFailure=yes નિષ્ફળ બાઇન્ડને તરત જ દૃશ્યમાન કરે છે, ફોરવર્ડિંગ વગરનું સેશન છોડવાને બદલે.

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

જો સેવાને રાત્રે ત્રણ વાગ્યે કોઈની નજર વગર જવાબ આપવો હોય, તો સર્વર-પ્રકાશિત પોર્ટવાળો આકાર ઓછા હલતા ભાગો ધરાવે છે, કારણ કે ચાલુ રહેવો જોઈએ તે એકમાત્ર પ્રક્રિયા ટનલ પોતે છે.

શરત બે: ફાયરવોલ અને લોગ કોના છે

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

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

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

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

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

શરત ત્રણ: એક પોર્ટ કે ઘણા, અને નામ કોનું છે

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

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

ત્રણ શરતોમાંથી કઈએ આકાર નક્કી કર્યો તે લખો. નહીંતર બીજી સેવા ઉમેરનાર આગલી વ્યક્તિ ઓછા સંદર્ભ સાથે એ જ સરખામણી ફરી ખોલશે.

નિર્ણય કરો, પછી બહારથી પરીક્ષણ કરો

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

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

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

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