CGNAT પાછળનો VPN સર્વર કેમ ક્યારેય કનેક્શન સ્વીકારતો નથી

રાઉટર 100.72 થી શરૂ થતું WAN સરનામું રિપોર્ટ કરે છે, ડાયનેમિક DNS નામ બીજા પબ્લિક સરનામે રિઝોલ્વ થાય છે, અને તે રાઉટરનો VPN સર્વર બહારથી ક્યારેય હેન્ડશેક પૂર્ણ કરતો નથી. પોર્ટ ફોરવર્ડિંગ ગોઠવેલું છે, સેવા ચાલી રહી છે, અને LAN થી પરીક્ષણ હજી કામ કરે છે. રાઉટર લોગમાં કંઈ પણ ભૂલ જેવું દેખાતું નથી. એ સંયોજન કેરિયર-ગ્રેડ NAT છે, અને ISP પાસે રહેલા સરનામા પર કોઈ ફાયરવોલ નિયમ પોર્ટ ખોલી શકતો નથી.

શેર કરેલું સરનામું ચકાસવામાં બે મિનિટ લાગે છે અને એક અઠવાડિયાના કન્ફિગરેશન ફેરફારો અટકાવે છે.

કેરિયર NAT તરફ ઇશારો કરતા સંકેતો

રાઉટરના સ્ટેટસ પેજ પરનું WAN સરનામું બહારના લુકઅપે રિપોર્ટ કરેલા સરનામા સાથે સરખાવો. 100.64.0.0/10 ની અંદરનું WAN સરનામું સામાન્ય સંકેત છે, અને ખાનગી રેન્જ 10/8, 172.16/12 અને 192.168/16 એ જ અર્થ ધરાવે છે. જો traceroute એક જ પબ્લિક હોપ વારંવાર બતાવે, અથવા શરૂઆતનો હોપ ખાનગી સરનામાથી જવાબ આપે, તો રાઉટર અને ઇન્ટરનેટ વચ્ચે બીજું ટ્રાન્સલેટર બેઠું છે. કેટલાક ISP ફાળવેલું સરનામું ફક્ત ગ્રાહક પોર્ટલમાં દર્શાવે છે, તેથી એ મૂલ્ય traceroute સાથે એક્સપોર્ટ કરો.

પ્રોટોકોલ કે પોર્ટ બદલવાથી મદદ મળતી નથી, કારણ કે સમસ્યા બંધ પોર્ટ નહીં, ઇનબાઉન્ડ પહોંચ છે.

ફોરવર્ડિંગ અને ડાયનેમિક DNS તેને કેમ સુધારી શકતા નથી

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

ગ્રાહકને ફરીથી ગોઠવવાથી પણ મદદ નહીં મળે, કારણ કે નિષ્ફળતા કોઈ પણ ગ્રાહક સેટિંગ વાંચવામાં આવે તે પહેલાં જ થાય છે.

સ્પષ્ટ રૂટ સાથે VPS દ્વારા રિલે

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

VPS પર ગ્રાહક-વિશિષ્ટ ડિરેક્ટરી એન્ટ્રી ઉમેરો જેથી સર્વરને ખબર પડે કે ઘરનું સબનેટ કયા પીઅરનું છે, અને મેળ ખાતું કર્નલ રૂટ ઉમેરો.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

iroute લાઇન OpenVPN ને કહે છે કે ઘરના સબનેટ માટેનો ટ્રાફિક કયો ગ્રાહક મેળવે છે; route લાઇન એ સબનેટને VPS ના કર્નલ ટેબલમાં મૂકે છે જેથી પેકેટ ટનલમાં દાખલ થાય. પ્રકાશિત સેવા માટે, પબ્લિક પોર્ટને 10.8.0.10 પર ફોરવર્ડ કરતો ડેસ્ટિનેશન NAT નિયમ ઉમેરો અને net.ipv4.ip_forward સક્ષમ કરો.

બહારથી માર્ગ ચકાસો

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

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

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

પહેલા ભાવ તપાસવા લાયક વિકલ્પો

ISP તરફથી સમર્પિત IPv4 સરનામું સૌથી ટૂંકો ઉપાય છે અને સામાન્ય રીતે નાની માસિક ફી છે. નેટિવ IPv6 બંને છેડે ટ્રાન્સલેશન દૂર કરે છે જ્યારે VPN, ગ્રાહક નેટવર્ક અને DNS રેકોર્ડ બધા તેને ધરાવે છે. ઘરના નેટવર્કમાં સબનેટ રાઉટર સાથેનું મેશ ઓવરલે VPS વિના એ જ રિલે આપે છે, પણ સંકલન સેવા પર નિર્ભરતાની કિંમતે.

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