ప్రోటోకాల్ 47 వర్సెస్ TCP పోర్ట్ 47: రెండు హెడర్లు, రెండు నియమాలు
ప్రోటోకాల్ నంబర్ మరియు పోర్ట్ వేర్వేరు హెడర్లలో నివసిస్తాయి, కాబట్టి ఒక నియమం మరొకదాన్ని భర్తీ చేయలేదు. PPTP రెండింటినీ వేరు చేస్తుంది, మరియు పోర్ట్ పెట్టె GREని వ్యక్తపరచలేదు.
హోటల్ నెట్వర్క్లు మరియు సమావేశ ఫైర్వాల్లు తరచుగా అనుకూల అనుమతి పెట్టెను చూపుతాయి, మరియు PPTP పని చేస్తుందని ఆశిస్తూ ఎవరో దానిలో 47 టైప్ చేస్తారు. నియమం సృష్టించబడుతుంది, టన్నెల్ ఇప్పటికీ విఫలమవుతుంది, మరియు తదుపరి ప్రయత్నం మరో నంబర్ను ఉపయోగిస్తుంది. తప్పు ప్యాకెట్లోనే ఉంది: IPv4లో IP హెడర్ తర్వాత ఏమి వస్తుందో పేరు పెట్టే ప్రోటోకాల్ ఫీల్డ్ ఉంది, అయితే TCP మరియు UDPలో పోర్ట్ ఫీల్డ్లు ఉన్నాయి, అవి ఆ హెడర్లలో ఒకదాని లోపల ఉన్నప్పుడే ఉంటాయి. ఇవి ఒకే అనుమతి యొక్క రెండు వర్ణనలు కావు.
IPv4 హెడర్ తదుపరి ప్రోటోకాల్కు పేరు పెడుతుంది
ప్రోటోకాల్ ఫీల్డ్ IPv4 హెడర్లో ఒక బైట్, మరియు అది పేలోడ్ను వివరించే సంఖ్యను ఉంచుతుంది: TCPకి 6, UDPకి 17, GREకి 47, ESPకి 50. ప్యాకెట్లను ఫిల్టర్ చేసేది ఏదైనా లోతుగా చూసే ముందు ఆ విలువను చదువుతుంది, ఎందుకంటే లోతైన హెడర్ రకం తెలిసిన తర్వాతే అర్థవంతం అవుతుంది. సంభాషణలో తర్వాత ఒక పోర్ట్ను మార్చండి, ఈ ఫీల్డ్ కదలలేదు.
కాబట్టి ప్రోటోకాల్ 47కి వ్యతిరేకంగా రాసిన నియమం IP పొరను వివరిస్తుంది. నిర్ణయంలో ఏ పోర్ట్ పాల్గొనదు.
పోర్ట్లు TCP మరియు UDP లోపల మాత్రమే ఉంటాయి
పోర్ట్లు TCP మరియు UDP హెడర్ల లోపల పదహారు-బిట్ గుర్తింపులు, వాటి పని ఒకే చిరునామాను పంచుకునే సంభాషణలను వేరు చేయడం. GRE హెడర్ ప్రోటోకాల్ రకం విలువను, తరచుగా EtherType, దానితో పాటు మల్టీప్లెక్సింగ్ కోసం ఐచ్ఛిక కీలను మోసుకుంటుంది. కాబట్టి పోర్ట్ 47 అనే పదబంధం GRE ప్యాకెట్ సరిపోలగల ఏదీ పేరు పెట్టదు.
ఫైర్వాల్ ఇంటర్ఫేస్లు ఇందులో ఎంత చూపుతాయనే విషయంలో భిన్నంగా ఉంటాయి. కొన్ని ప్రోటోకాల్ నంబర్ను అంగీకరిస్తాయి, కొన్ని పేర్లతో కూడిన జాబితాను అందిస్తాయి, కొన్ని మాత్రమే పోర్ట్లతో TCP లేదా UDPని అంగీకరిస్తాయి.
PPTP రెండు పొరలను ఒకేసారి ఉపయోగిస్తుంది
PPTP అత్యంత స్పష్టమైన ఉదాహరణ ఎందుకంటే అది తన పనిని రెండు పొరల మధ్య ఉద్దేశపూర్వకంగా విభజిస్తుంది. నియంత్రణ కనెక్షన్ పోర్ట్ 1723కి TCP సెషన్, మరియు డేటా మార్గం GRE, ప్రోటోకాల్ 47, ఎక్కడా ఏ పోర్ట్ పాల్గొనదు. 1723కి మాత్రమే అనుమతి ఇచ్చే ఫైర్వాల్ చర్చలు ప్రారంభం కానిచ్చి ఆపై పేలోడ్ను పారవేస్తుంది. టన్నెల్ కనెక్ట్ కాకుండా ఉండటం బదులు ప్రామాణీకరణ తర్వాత వేలాడుతున్నట్లు కనిపిస్తుంది, అందుకే లక్షణం తరచుగా పాస్వర్డ్ సమస్యగా నివేదించబడుతుంది.
| Path | Outer protocol | Port |
|---|---|---|
| Control channel | TCP, protocol 6 | 1723 |
| Data channel | GRE, protocol 47 | None |
నియమం రాసేటప్పుడు రెండు వరుసలను విడివిడిగా చదవండి, ప్రతిదాన్ని విక్రేత సింటాక్స్తో తనిఖీ చేయండి. ఒక వరుసకు పోర్ట్ కావాలి, మరొకదానికి ప్రోటోకాల్ నంబర్ కావాలి, ఏ ఒక్క ఎంట్రీ రెండింటినీ కవర్ చేయదు.
పోర్ట్-ఫార్వర్డ్ పేజీ GREని ఎందుకు వ్యక్తపరచలేదు
TCP మరియు UDP మాత్రమే అంగీకరించే ఫార్వర్డింగ్ ఫారమ్ GREని వివరించలేదు, ఫారమ్ పేరు ఏదైనా. చిరునామా అనువాదం రెండవ ఇబ్బందిని జోడిస్తుంది, ఎందుకంటే GREకి పోర్ట్లు లేవు మరియు అనువాదకుడు బదులుగా కాల్ గుర్తింపును అనుసరించాలి. కొన్ని వినియోగదారు రౌటర్లతో దీన్ని నిర్వహించే సహాయకుడు వస్తాడు; చాలా వాటితో రాదు, మరియు ఏ అదనపు TCP అనుమతి ఎంట్రీ ఆ ప్రవర్తనను సృష్టించదు.
నిజమైన అవసరం ఆధునిక టన్నెల్ అయినప్పుడు, అనువాదకుడు సరిగ్గా ఊహిస్తాడని ఆశించడం బదులు ఉద్దేశపూర్వకంగా TCP లేదా UDPని ఉపయోగించే రూపకల్పనను ఎంచుకోండి.
ఎన్క్యాప్సులేషన్ ఫిల్టర్ ఏమి చూస్తుందో నిర్ణయిస్తుంది
ఎన్క్యాప్సులేషన్ బయటి ప్యాకెట్ను మారుస్తుంది, మరియు నియమం సరిపోలేది ఆ బయటి ప్యాకెట్తోనే. స్థానిక ESP ప్రోటోకాల్ 50, అయితే NAT దాటడం ESPని UDP 4500 లోపల చుట్టి చిరునామా అనువాదం నుండి దాటిస్తుంది. UDP 4500కి అనుమతి ఇచ్చే ఫిల్టర్ ప్రోటోకాల్ 50ని ఎప్పుడూ చూడదు, మరియు ప్రోటోకాల్ 50 కోసం రాసిన ఫిల్టర్ చుట్టిన రూపంతో ఎప్పుడూ సరిపోలదు.
క్లయింట్ మరియు గేట్వే ఏ ఎన్క్యాప్సులేషన్కు అంగీకరించాయో అడగండి, తర్వాత నియమాన్ని సరిగ్గా ఆ బయటి ఆకారానికే రాయండి, దానికి మించి ఏమీ లేదు.
ఎవరైనా తనిఖీ చేయగలిగేలా నియమాన్ని రాయండి
ప్రతి నియమాన్ని చిరునామా కుటుంబం, బయటి ప్రోటోకాల్, ఉంటే రవాణా పోర్ట్లు, దిశ మరియు రెండు చివరలుగా వ్యక్తపరచండి. సమీక్షకుడు ఆ వాక్యాన్ని ప్యాకెట్ క్యాప్చర్తో పోల్చి తీర్పుకు రాగలరు. 47 తెరవాలనే సూచనను ఎవరూ తనిఖీ చేయలేరు, అందుకే అది సంవత్సరాల తరబడి విధాన పుస్తకాలలో నిలిచి ఉంటుంది.
దాన్ని నిరూపించే పరీక్షను జోడించండి: బయటి ఇంటర్ఫేస్లో క్యాప్చర్ చేస్తూ కనెక్ట్ అవ్వండి, మరియు ట్రేస్లో నిజంగా కనిపించే బయటి ప్రోటోకాల్ మరియు పోర్ట్ను నిర్ధారించండి.