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 ක්‍රියා නොකරන තෙක් පෝට් ප්‍රතික්ෂේප කරන සෞඛ්‍ය පරීක්ෂාවකට පේළි කිහිපයක් ගත වන අතර පැයක අනුමානයක් ඉතිරි කරයි. ඉන්පසු නියම සංස්කරණය කිරීම නවත්වා එය විශ්වාස කිරීමට පෙර දිනක් නිරීක්ෂණය කරන්න.