స్థిర UDP పోర్ట్‌లు పోర్ట్ ఫార్వర్డింగ్‌ను దాటవేయగలవు, కానీ ప్రతి NAT కాదు

రెండు ఇంటి రౌటర్లు, ఏ పోర్టూ ముందుకు పంపబడలేదు, అయినా కొన్నిసార్లు కనెక్ట్ అయ్యే VPN. UDP దీన్ని అనుమతిస్తుంది, ఎందుకంటే యంత్రం ఇప్పటికే ప్రారంభించిన ప్రవాహంతో సరిపోల్చగల ప్యాకెట్‌ను ఫైర్‌వాల్ అంగీకరిస్తుంది. ఇది లక్షణం కాదు, షరతులతో కూడిన ఉపాయం, ఫైర్‌వాల్ ఏమి పోలుస్తుందో తెలిస్తే షరతులు చెప్పడం సులభం. ఒకే ప్రొఫైల్‌లు వేర్వేరు నెట్‌వర్క్‌లలో వేర్వేరుగా ప్రవర్తించడానికి కూడా ఇదే కారణం.

ఫైర్‌వాల్ చేసే పోలిక

ప్రతి బయటకు వెళ్లే డేటాగ్రామ్ ఒక స్వల్పకాలిక నమోదును సృష్టిస్తుంది: మూల చిరునామా, మూల పోర్ట్, గమ్య చిరునామా, గమ్య పోర్ట్. నమోదుతో సరిపోలే ఏదైనా సమాధానంగా పరిగణించి అనుమతించబడుతుంది. లోపలికి వచ్చే నియమాలకు ఇందులో ఎలాంటి పాత్రా లేదు.

కాబట్టి ప్రశ్న ఫైర్‌వాల్ భాగస్వామిని లోపలికి అనుమతిస్తుందా అని కాదు. ప్రశ్న ఏమిటంటే భాగస్వామి ప్యాకెట్ నమోదు ఎదురుచూస్తున్న సమాధానం లాగా కనిపిస్తుందా అని. ఆ నాలుగు భాగాల ట్యూపుల్‌లో ఒక ఫీల్డ్ మార్చండి, ప్యాకెట్ అపరిచితంగా మారుతుంది. అందుకే పోర్ట్ నంబర్ మాత్రమే మారినప్పుడు పనిచేసిన సెటప్ విరిగిపోవచ్చు, అందుకే ఒకే పోర్ట్ ఒక రౌటర్‌లో పనిచేసి తదుపరి దానిలో విఫలమవుతుంది.

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

ప్రతి చివర ఒక పోర్ట్‌ను స్థిరపరచడం

OpenVPN యొక్క డిఫాల్ట్ UDP పోర్ట్ 1194, మరియు lport అది ఏ పోర్ట్ నుండి పంపుతుందో నిర్ణయిస్తుంది. రెండు భాగస్వాములను స్థిరపరచండి, ప్రతి ఒక్కటి బయటకు వెళ్లే ట్యూపుల్ మరొకటి వింటున్న పోర్ట్ వైపు చూపుతుంది:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

ఇది వాటి మధ్య ఏ రౌటర్ కూడా మూల పోర్ట్‌ను తిరిగి రాయనంత వరకే పనిచేస్తుంది. ప్యాకెట్‌లు క్యాప్చర్‌లో కనిపించినా టన్నెల్ లేకపోతే, తిరిగి రాయడమే మొదటి అనుమానం.

ట్యూపుల్ సరిపోవడం ఆగే చోటు

గమ్యం ప్రకారం మ్యాప్ చేసే NAT ప్రతి భాగస్వామికి వేరే బాహ్య పోర్ట్ ఇస్తుంది. మీ భాగస్వామికి ఉపయోగించమని చెప్పిన చిరునామా అతన్ని చేరే చిరునామా కాదు, కాబట్టి వచ్చే ప్యాకెట్ దేనితోనూ సరిపోలక నిశ్శబ్దంగా పడవేయబడుతుంది.

ఆపరేటర్ స్థాయి అనువాదం, పొరల NAT మరియు పోర్ట్ యాదృచ్ఛికీకరణ అన్నీ ఒకేలా ముగుస్తాయి. చిరునామాలను ముట్టుకోకుండా పోర్ట్‌లను తిరిగి రాసే ఏ మధ్య పెట్టె అయినా అలాగే.

స్ట్రీమ్ రవాణా పరిస్థితి మరింత దారుణం. TCP హ్యాండ్‌షేక్ అడుగు అడుగుగా ట్రాక్ చేయబడుతుంది, కాబట్టి TCP ఆధారిత VPN ఈ విధంగా అసలు కుట్టలేదు, మార్గంలో ఎక్కడో వినేవాడు కావాలి.

సాధారణంగా ఒక వైపు మొదట విఫలమవుతుంది

ఆచరణలో రెండు నెట్‌వర్క్‌లు అరుదుగా ఒకేలా ప్రవర్తిస్తాయి. ఒక రౌటర్ ఊహించదగిన మ్యాపింగ్ ఇవ్వవచ్చు, మరొకటి గమ్యం ప్రకారం పోర్ట్‌లు ఇస్తుంది, ఫలితం రెండు ఇళ్ల మధ్య పనిచేసి మొబైల్ నెట్‌వర్క్ నుండి విఫలమయ్యే కాన్ఫిగరేషన్. ఒకదానికొకటి విరుద్ధమైన నివేదికలు సాధారణంగా రెండు వేర్వేరు రౌటర్ జంటలను వివరిస్తాయి. ఏ రచయితా తప్పు కాదు, ఏ ఫలితమూ సాధారణీకరించబడదు.

ప్రొఫైల్‌లను తాకే ముందు ఏ వైపు ప్యాకెట్‌ను పడవేసిందో కనుగొనండి. రెండు చివరల క్యాప్చర్ ఒకే ప్రయత్నంలో దీన్ని తేలుస్తుంది: A నుండి బయలుదేరి B చేరని డేటాగ్రామ్‌లు ప్రవాహం మార్గంలో తిరిగి రాయబడిందని అర్థం, B చేరి సమాధానం తిరిగి రాని డేటాగ్రామ్‌లు ఫైర్‌వాల్ వాటిని సంబంధితంగా అంగీకరించలేదని అర్థం.

ప్రజా IPv6 చిరునామాలు ఉన్న ఇద్దరు భాగస్వాములు మొత్తం సమస్యను దాటవేస్తారు. అనువాదం లేకుండా సరిపోల్చడానికి ఏమీ లేదు, కాబట్టి భాగస్వాములను పేర్కొనే ఫైర్‌వాల్ నియమం సరిపోతుంది, డిజైన్ రౌటర్ ప్రవర్తనపై ఆధారపడటం మానేస్తుంది.

ఎప్పుడు ప్రయత్నం ఆపాలి

ప్రజా చిరునామా ఉన్న హోస్ట్ నమ్మదగిన సమాధానం. అది ఇద్దరు భాగస్వాములకూ టన్నెల్ ముగించగలదు, లేదా ఒకరి ప్రస్తుత బాహ్య చిరునామాన్ని మరొకరు కనుగొనడంలో సహాయపడగలదు, NAT ఏమి చేసినా రెండు ఏర్పాట్లూ పనిచేస్తాయి. విధానం అనుమతిస్తే నిర్వహిత ఓవర్‌లే అదే సమన్వయాన్ని అందిస్తుంది.

వీటిలో ఏదీ ఆఫ్ చేసిన ఫైర్‌వాల్ అవసరం లేదు. ప్రత్యక్ష కనెక్షన్ గెలవడానికి రక్షణను ఆఫ్ చేయడం ప్రత్యక్ష ప్రయత్నాన్ని ఆకర్షణీయంగా చేసిన కారణాన్ని పడవేస్తుంది, పరీక్ష మొత్తం కాలం యంత్రాన్ని తెరిచి ఉంచుతుంది.

మొదట ప్రత్యక్ష ఏర్పాటును ప్రయత్నించండి, తర్వాత చూసినది రాయండి. NAT ప్రవర్తన మరియు దాన్ని చూపిన క్యాప్చర్ చివరిలో ఉపయోగించిన పోర్ట్ జత కంటే విలువైనవి, ఎందుకంటే తదుపరి నెట్‌వర్క్ భిన్నంగా ఉంటుంది. OpenVPN 2.6 మాన్యువల్ డాక్యుమెంట్ చేస్తుంది lport మరియు ఇది ఆధారపడే remote ఎంపికలను.