రౌటర్‌లో VPN లేదా పోర్ట్ ఫార్వర్డింగ్: ఏది గెలుస్తుంది?

రౌటర్ VPNని తనే ముగిస్తుంది, మరియు పాత ఫార్వర్డింగ్ నియమం ఇప్పటికీ అదే UDP పోర్ట్ను LANలోని ఒక మెషీన్కు పంపుతుంది. వాటిలో ఒకటి మాత్రమే నిజమైన చివరి బిందువు కాగలదు, మరియు కెర్నల్ వాటి మధ్య నిర్ణయించదు. గమ్యస్థాన అనువాదం స్థానిక సేవను అడిగే ముందే ప్యాకెట్ను తిరిగి రాస్తుంది, కాబట్టి VPN ప్రక్రియ ఇప్పటికే మరెక్కడో పంపబడిన ట్రాఫిక్ కోసం వేచి ఉంటుంది. పని పోర్ట్ ఎవరిదో నిర్ణయించడం, ఆ తర్వాత నియమాలను సరిపోల్చడం.

ఒక పోర్ట్, ఇద్దరు క్లెయిమ్ చేసే యజమానులు

రౌటర్ లోపల నడుస్తున్న VPN సర్వర్కు తన సొంత సాకెట్కు దారి తీసే ఇన్బౌండ్ అనుమతి అవసరం. అదే పోర్ట్ కోసం గమ్యస్థాన-NAT ఎంట్రీ పూర్తిగా మరెక్కడోకి తీసుకెళుతుంది: LAN చిరునామా మరియు ఫార్వర్డింగ్ నిర్ణయం. ఇవి వేర్వేరు లాగ్లు మరియు వేర్వేరు వైఫల్య విధానాలు కలిగిన వేర్వేరు చివరి బిందువులు. సాధారణ సూచన ఏమిటంటే ఒక చిరునామా కుటుంబం పనిచేస్తుంది, మరొకటి పనిచేయదు, ఎందుకంటే మిగిలిన ఎంట్రీ ఒకే కుటుంబానికి రాయబడింది మరియు మళ్లీ సమీక్షించబడలేదు.

సవరించే ముందు క్లెయిమ్ను రాయండి: కుటుంబం, బాహ్య చిరునామా, రవాణా, పోర్ట్ మరియు అనువదించిన లక్ష్యం.

స్థానిక తనిఖీకి ముందే అనువాదం నడుస్తుంది

గమ్యస్థాన NAT కెర్నల్ స్థానిక డెలివరీ మరియు ఫార్వర్డింగ్ మధ్య ఎంచుకునే ముందు, ప్రీ-రౌటింగ్ దశలో ప్యాకెట్ లక్ష్యాన్ని మారుస్తుంది. లక్ష్యం LAN హోస్ట్ అయిన వెంటనే ప్యాకెట్ ఫార్వర్డింగ్ మార్గాన్ని తీసుకుంటుంది. రౌటర్ సొంత సాకెట్ కోసం ఇన్పుట్ నియమాలు ఎప్పుడూ పరిగణించబడవు, అందుకే క్లయింట్ వేచి ఉన్నప్పుడు VPN లాగ్ ఖాళీగా ఉంటుంది.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

ఈ క్రమమే మొత్తం యంత్రాంగం, పరికర ఇంటర్ఫేస్లు దాన్ని మార్చకుండా చెక్బాక్స్ వెనుక దాస్తాయి. ప్యాకెట్ ఏ మార్గం తీసుకుంటుందో ఇప్పటికీ గమ్యస్థాన యజమానే నిర్ణయిస్తాడు.

LAN హోస్ట్ ఉద్దేశించిన చివరి బిందువు అయితే, ఫార్వర్డింగ్ సరైనది మరియు రౌటర్ అదే పోర్ట్లో కూడా వినకూడదు.

ఒక మ్యాపింగ్ ఉంచండి మరియు మరొకటి తీసివేయండి

ఆ పోర్ట్ మరియు కుటుంబానికి NAT ఎంట్రీలను జాబితా చేసి, మిగిలేదాన్ని ఎంచుకోండి:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

అదే సంఖ్య కలిగిన TCP ఎంట్రీ UDP వైఫల్యానికి అసంబద్ధం, వాటిని ఒకే వస్తువుగా పరిగణించడం తప్పు నియమాన్ని తొలగించడానికి దారితీస్తుంది. స్థానిక సాకెట్ గెలవాల్సినప్పుడు, ఘర్షణలో ఉన్న మ్యాపింగ్ యజమాని ఆ ఒక ఎంట్రీని తీసివేస్తాడు లేదా తిరిగి రాస్తాడు, రౌటర్ సొంత పోర్ట్ కోసం ఇన్బౌండ్ అనుమతి దాని స్థానంలో ఉంటుంది. సంబంధం లేని ఫార్వర్డింగ్లు, నిర్వహణ మార్గం మరియు నియమాల సమాహారం యొక్క కాపీ—అన్నీ ఈ మార్పును తట్టుకోవాలి.

VPN వేరే హోస్ట్లో నివసిస్తే, ఫార్వర్డింగ్ సరైన వస్తువు. కంటైనర్ లేదా వర్చువల్ మెషీన్లోని సేవకు, పెట్టెను రౌటర్ అని పిలిచినా ప్రచురిత పోర్ట్ అవసరం కావచ్చు, కాబట్టి కేస్పై ఉన్న లేబుల్ కాదు, సాకెట్ మరియు దాని నేమ్స్పేస్ను అనుసరించండి.

బయటి నుండి యజమానిని నిర్ధారించండి

ప్రతి కుటుంబాన్ని విడివిడిగా పరీక్షించండి, ఎందుకంటే రౌటర్లో ముగిసే IPv6 కనెక్షన్ పాత నియమం రీడైరెక్ట్ చేసే IPv4 కనెక్షన్ గురించి ఏమీ చెప్పదు. ఏ చివరి బిందువు సమాధానం ఇచ్చిందో చూడటానికి స్వీకరించే సేవ లాగ్ చదవండి, క్లయింట్ విజయ సందేశాన్ని బలహీన సాక్ష్యంగా పరిగణించండి. అర్థవంతమైన పరీక్షకు కొత్త ప్రవాహం అవసరం. బాహ్య హోస్ట్ నుండి nc -zvu 203.0.113.7 1194 తో ప్రోబ్ పంపి, విజేత లాగ్ను journalctl -u openvpn@server -n 20 తో చదవండి. రౌటర్ శ్రోత కనెక్షన్ను తానే లాగ్ చేస్తుంది, LAN హోస్ట్ దాన్ని తన సొంత సేవలో లాగ్ చేస్తుంది.

కనెక్షన్ ట్రాకింగ్ ఉన్న ప్రవాహాలను వాటి అసలు మ్యాపింగ్లో ఉంచుతుంది, కాబట్టి స్థాపించిన సెషన్ మీరు ఇప్పుడే సరిచేసిన నియమం కంటే ఎక్కువ కాలం జీవించగలదు.

ఉద్దేశించిన చివరి బిందువు తన సాధారణ గుర్తింపు తనిఖీలతో సమాధానం ఇచ్చిన తర్వాత, సొరంగం వెనుక ఉన్న ప్రైవేట్ వనరును పరీక్షించండి. బయటి శ్రోతను చేరుకోవడం మొదటి అడుగు మాత్రమే; అంతర్గత రౌటింగ్ మరియు అప్లికేషన్ అధికారం వేర్వేరు ఫలితాలు.