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 పని చేయనంత వరకు పోర్టును తిరస్కరించే ఆరోగ్య తనిఖీ కొన్ని పంక్తుల ఖర్చు, ఒక గంట ఊహను ఆదా చేస్తుంది. ఆ తర్వాత నియమాలను సవరించడం ఆపి, దాన్ని నమ్మే ముందు ఒక రోజు గమనించండి.