જ્યારે CGNAT પોર્ટ બ્લોક કરે ત્યારે VPS દ્વારા ઘરનું સર્વર પ્રકાશિત કરવું

મેં બહારથી શરૂ કર્યું, જેમ કોઈ વપરાશકર્તા કરે: નામને મોબાઇલ ડેટા પર ફોનના બ્રાઉઝરમાં લખ્યું અને જોયું કે કનેક્શન સમય પૂરો થાય ત્યાં સુધી લટકતું રહ્યું. નામ ઉકેલાતું હતું, એટલે DNS ઠીક હતું. ઘરના રાઉટરનું પોર્ટ-ફોરવર્ડિંગ પૃષ્ઠ પણ બંધ ગલી હતું, કારણ કે તેનું WAN સરનામું 100.64.31.42 દેખાડતું હતું, અને આ એવું સરનામું નથી જ્યાં કોઈ પ્રદાતા મને ઇન્ટરનેટથી મોકલે. આ સંખ્યા આખી ખામી સમજાવે છે: લાઇન carrier-grade NAT પાછળ છે, એટલે સુરંગના મારા તરફના જાહેર સરનામું પ્રદાતાનું છે. આગળ એ રસ્તો છે જે મેં તે અટકેલા ટૅબથી જવાબ આપતી સેવા સુધી કાપ્યો.

ક્લાઇન્ટથી શરૂ કરો અને અંદર તરફ જાઓ

કોઈ પણ નિયમ બદલતા પહેલાં સાબિત કરો કે સાંકળ ક્યાં અટકે છે. લૅપટોપ પર મેં dig +short files.example.net ચલાવ્યું અને VPSનું સરનામું પાછું મળ્યું, જેણે મારા મશીન પર જૂનું DNS બાકાત કર્યું. પછી curl -v --connect-timeout 5 files.example.net:5022 નકારાવાને બદલે સમય પૂરો થઈને અટકી ગયું. આ ફરક મહત્ત્વનો છે: સમય પૂરો થવો સામાન્ય રીતે એટલે પેકેટ રસ્તામાં ફેંકાઈ રહ્યા છે, જ્યારે નકાર એટલે કંઈકે જવાબ આપ્યો અને ના કહી.

અંદર તરફનું બીજું પગલું પોતે VPS હતું. ss -ltnp એ એવું કંઈ દેખાડ્યું નહીં જે 5022 પર સાંભળતું હોય, જે DNAT નિયમ બનતા પહેલાં અપેક્ષિત હતું. તે જ મશીન પર wg show (અથવા OpenVPN માટે ip -br a show tun0) એ પુષ્ટિ કરી કે ઘરનો peer સક્રિય છે અને તેનું handshake તાજું છે. જો peer કામ ન કરે તો કોઈ NAT નિયમ મદદ નહીં કરે, અને ઘરના રાઉટરના VPN પૃષ્ઠ પરની લીલી બત્તી કંઈ અર્થ રાખતી નથી.

ખાતરી કરો કે ઘરની લાઇન ખરેખર CGNAT પાછળ છે

રાઉટર જે સરનામું તેના WAN ઇન્ટરફેસ પર જણાવે છે તેની તુલના બહારની સેવા જે જુએ છે તેની સાથે કરો. 100.64.0.0/10માં જે કંઈ છે, એટલે 100.64.x.x થી 100.127.x.x સુધી, તે RFC 6598ની સહિયારી સરનામાં-શ્રેણી છે અને ઇન્ટરનેટથી પહોંચની બહાર છે. એ જ નિષ્કર્ષ પર તમે ત્યારે પણ પહોંચો છો જ્યારે રાઉટર કોઈ સામાન્ય ખાનગી સરનામું હોવાનો દાવો કરે અને જાહેર શોધ કંઈ અસંબંધિત પાછું આપે. CGNAT લાઇન સાથે એવું જાહેર સરનામું પણ આવી શકે જે ફક્ત આગલા lease સુધી ટકે, એટલે પોર્ટ ફોરવર્ડિંગ એક કલાક કામ કરતું દેખાય અને પછી ચૂપચાપ મરી જાય.

કેટલાક પ્રદાતા ખરેખર સાચું જાહેર સરનામું આપે છે, પણ રહેણાંક ખાતાઓ પર આવતા 80 અને 443 પોર્ટ બ્લોક કરે છે. જો તમારી સેવા ફક્ત વેબ હોય અને WAN સરનામું ખરેખર જાહેર હોય, તો relay બનાવતા પહેલાં સહાયતાને પૂછો. જો ન હોય, તો નીચેની રચના દરેક પોર્ટ પર સરખી રીતે લાગુ પડે છે, અને પ્રયોગને રાઉટરની બાજુએ રોકવો વધુ સારો છે: પ્રદાતાના નેટવર્કમાંનો અનુવાદક કનેક્શનને ખતમ કરે છે તે પહેલાં કે તે ક્યારેય તમારા WAN ઇન્ટરફેસ સુધી પહોંચે.

નામને VPSના સરનામા તરફ નિર્દેશ કરો

DNS ટ્રાફિક આગળ મોકલતું નથી, એટલે સેવાના A રેકોર્ડમાં VPSનું જાહેર સરનામું હોવું જોઈએ. 192.168.1.20 તરફનો A રેકોર્ડ ફક્ત એ ક્લાઇન્ટ માટે ઉપયોગી રીતે ઉકેલાય છે જેઓ પહેલેથી VPNમાં છે; ઇન્ટરનેટથી તે એવા સરનામા પર ઉકેલાય છે જેને કોઈ રૂટ કરી શકતું નથી. પોતે VPSની વહીવટી પહોંચ માટે હું અલગ નામ રાખું છું, જેથી ક્યારેય એ ગૂંચવાય નહીં કે રેકોર્ડ કયા હોસ્ટ સાથે સંબંધિત છે.

જો VPS અને ઘરનું મશીન બંને HTTP પરોસે છે, તો દરેકને પોતાનું નામ આપો અને VPSને નક્કી કરવા દો કે કોણ જવાબ આપે છે. બંનેને એક નામમાં સમેટીને એ આશા રાખવી કે પ્રોક્સી સાચું backend પસંદ કરશે, એ ચોક્કસ એ જ રીત છે જેનાથી તમે આખી બપોર ખોટા હોસ્ટ પર ભૂલ શોધો છો.

એક પોર્ટ DNAT પર, SSH 22 પર રહે

સીધો વિકલ્પ VPS પર ગંતવ્ય NAT છે. ચાલતા કર્નલ માટે forwarding સક્ષમ કરો અને નિયમમાં ઘરના સર્વરનું સુરંગ સરનામું રાખો, તેનું LAN સરનામું નહીં:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

પોતે VPS સુધી SSHને 22 પર રહેવા દો અને બીજું પોર્ટ, જેમ કે 5022, ઘરના મશીન તરફ મોકલો. જો 22 કોઈ બંધ મશીન તરફ મોકલશો તો એ એકમાત્ર રસ્તો ગુમાવશો જે તેને ઠીક કરી શકતો હતો. એ જ તર્ક પ્રોક્સી પર પણ લાગુ પડે છે: VPSનું વ્યવસ્થાપન પોર્ટ relay નિયમોની બહાર રાખો.

નિયમો કામ કરવા લાગે ત્યારે તેમને કાયમી બનાવો. Debian અથવા Ubuntu પર apt install iptables-persistent અને પછી netfilter-persistent save તેમને /etc/iptables/rules.v4માં લખે છે. firewalld વાળા હોસ્ટ પર એનું સમતુલ્ય ઝોનમાં કાયમી પોર્ટ ફોરવર્ડિંગ છે, જેને લાગુ થવા પહેલાં firewall-cmd --reload જોઈએ. ફક્ત મેમરીમાં રહેતા નિયમો પ્રદાતાના પહેલા જાળવણી રીબૂટ પર અદૃશ્ય થઈ જાય છે, સામાન્ય રીતે ખરાબ સમયે.

પરતનો રસ્તો સુધારો અથવા તેની જરૂરિયાત ટાળો

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

બે સુધારા કામ કરે છે. ઘરના મશીનને નીતિ-માર્ગ આપો જેથી સુરંગમાંથી આવતો ટ્રાફિક સુરંગ થઈને પાછો જાય:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

અથવા VPSને સ્રોત ફરી લખવા દો જેથી જવાબ પાસે એવું સરનામું હોય જ્યાં તે પહોંચી શકે, અને conntrack તેને બહાર જતાં પલટી દે:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT આવૃત્તિ સાચું ક્લાઇન્ટ સરનામું ઘરના સર્વરથી છુપાવે છે, એટલે એપ્લિકેશન લૉગ peer તરીકે 10.8.0.1 દેખાડે છે. મૂળ સરનામું એપ્લિકેશન સ્તરે આગળ મોકલો, અથવા પ્રતિ ક્લાઇન્ટ લૉગિંગનું નુકસાન સ્વીકારો, પણ આ નિર્ણય સભાનપણે લો, કોઈ ઘટના દરમિયાન એ શોધવાને બદલે.

આખો રસ્તો બહારથી ચકાસો

એવા નેટવર્કથી ચકાસો જે ન VPS છે ન ઘર: મોબાઇલ ડેટા પરનો ફોન, અથવા બીજે ક્યાંક સસ્તું shell. nc -vz files.example.net 5022 એ સફળ કનેક્શનની જાણ કરવી જોઈએ, અને openssl s_client -connect files.example.net:443 -servername files.example.net એ જાહેર નામ માટે પ્રમાણપત્ર દેખાડવું જોઈએ. પછી પ્રદાતાનો સુરક્ષા જૂથ અથવા ક્લાઉડ ફાયરવૉલ તપાસો. એવો DNAT નિયમ જે ક્યારેય પેકેટ જોતો નથી, સામાન્ય રીતે હોસ્ટથી એક સ્તર ઉપર બ્લોક થાય છે.

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