WireGuard హ్యాండ్‌షేక్ పని చేస్తుంది, సేవ కాదు

హ్యాండ్‌షేక్ పూర్తవుతుంది, క్లయింట్ ఇటీవలి బదిలీ కౌంటర్‌ను చూపిస్తుంది, అయినా అదే సర్వర్‌లోని సేవకు చేసిన అభ్యర్థన విఫలమవుతుంది. ఈ కలయిక ప్రజలను గందరగోళపరుస్తుంది, ఎందుకంటే సొరంగం స్పష్టంగా పని చేస్తోంది. నిరూపించబడనిది స్థానిక డెలివరీ: ప్యాకెట్ హోస్ట్‌ను చేరుకుంది, మరియు హోస్ట్ దాన్ని సరైన సాకెట్‌పై అంగీకరించి ప్రత్యుత్తరం ఇవ్వడానికి అనుమతి ఉన్న ప్రక్రియకు ఇవ్వాలి. ఈ మూడు తనిఖీ పాయింట్లను క్రమంగా చూడండి.

సరిపోని మొదటి దాని వద్ద ఆగండి, మిగిలిన వాటికి నియమాలు జోడించవద్దు.

హ్యాండ్‌షేక్ సొరంగాన్ని మాత్రమే నిరూపిస్తుంది

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

చివరి భేదమే ఎక్కువగా తప్పిపోతుంది: హోస్ట్‌కే వెళ్లే ట్రాఫిక్ స్థానిక ఇన్‌పుట్, కానీ హోస్ట్ గుండా వేరొక చోటికి వెళ్లే ట్రాఫిక్ ఫార్వార్డింగ్. వాటిని వేర్వేరు ఫైర్‌వాల్ చైన్‌లు మరియు వేర్వేరు సెట్టింగ్‌లు నిర్వహిస్తాయి. తప్పు చైన్‌ను తనిఖీ చేస్తే మధ్యాహ్నం వృథా అవుతుంది మరియు నిర్దోషిగా కనిపించే కౌంటర్లు తిరిగి వస్తాయి.

వినిపించేది మరియు మార్గాన్ని చదవండి

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

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1 పై వినిపించేది, ఫైర్‌వాల్ ఏమి అనుమతించినా, 10.66.0.1 కు పంపిన అభ్యర్థనకు ఎప్పటికీ ప్రత్యుత్తరం ఇవ్వదు. సాధారణ చిరునామాపై వినిపించేది, నియమం నిరోధించకపోతే ప్రత్యుత్తరం ఇస్తుంది. కాబట్టి ఏ నియమాన్ని చూడకముందే సాకెట్ జాబితా సగం కేసులను పరిష్కరిస్తుంది. పోర్టు మరియు చిరునామా కలిసి అభ్యర్థన చేరగలదా అని నిర్ణయిస్తాయి.

క్లయింట్ ఉపయోగించే చిరునామాను, సర్వర్ సొరంగ ఇంటర్‌ఫేస్‌పై నిజంగా కలిగి ఉన్న చిరునామాతో పోల్చండి. ఏ వైపైనా పాత కాన్ఫిగరేషన్, ఆ చిరునామా లేని సహచరుడి వైపు సరిగ్గా రూట్ అయ్యే అభ్యర్థనను సృష్టిస్తుంది.

స్థానిక ఇన్‌పుట్‌కు నియమాలు వర్తింపజేయండి, ఫార్వార్డింగ్‌కు కాదు

ప్యాకెట్ వచ్చి సాకెట్ ఉంటే, మిగిలిన సరిహద్దు ఇన్‌పుట్ విధానం. ఫార్వార్డింగ్‌ను అనుమతించే నియమం స్థానిక డెలివరీని అనుమతించదు, మరియు ఒక ఇంటర్‌ఫేస్‌కు పరిమితమైన నియమం మీరు ఆశించే సొరంగ ఇంటర్‌ఫేస్ పేరుతో సరిపోకపోవచ్చు.

హోస్ట్‌ను తెరవడం బదులు ఉద్దేశించిన సేవకు ఒకే అనుమతించిన పోర్టుతో పరీక్షించండి. తర్వాత అప్లికేషన్ సొంత అధికారాన్ని తనిఖీ చేయండి: అనుమతి జాబితా, ఖాతా అవసరం లేదా నిర్దిష్ట హోస్ట్ పేరుకు బంధనం నెట్‌వర్క్ విజయవంతంగా పంపిన అభ్యర్థనను తిరస్కరించవచ్చు.

సర్టిఫికెట్ తనిఖీలను అలాగే ఉంచండి. ఊహించని సర్టిఫికెట్ గుర్తింపు ఏ హోస్ట్ ప్రత్యుత్తరం ఇచ్చిందనే సమాచారం, తప్పించుకోవలసిన అడ్డంకి కాదు. దానిపై క్లిక్ చేసి ముందుకు వెళ్లడం తప్పు సేవను గుర్తించే ఏకైక ఆనవాలును దాచుతుంది.

పేరు, పరిమాణం మరియు గుర్తింపు వైఫల్యాలను వేరు చేయండి

చిరునామా ద్వారా పని చేసి పేరు ద్వారా విఫలమయ్యే సేవ DNS సమస్య, పరిష్కారం ఫైర్‌వాల్‌లో కాదు, క్లయింట్‌కు పంపే రిజాల్వర్ కాన్ఫిగరేషన్‌లో ఉంది. చిన్న అభ్యర్థనలకు ప్రత్యుత్తరం ఇచ్చి పెద్ద ప్రతిస్పందనలలో నిలిచిపోయే సేవ ప్యాకెట్ పరిమాణం మరియు MTU ను సూచిస్తుంది, అది పూర్తిగా వేరే దర్యాప్తు.

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

ఏ తనిఖీ పాయింట్ విఫలమైందో నమోదు చేయండి: సాకెట్, ఇన్‌పుట్ నియమం లేదా అప్లికేషన్ విధానం. ఆ ఒక్క వరుస నెట్‌వర్క్ లోపాన్ని అధికార నిర్ణయం నుండి వేరు చేస్తుంది. ఎప్పుడూ సమస్య కాని పోర్టులను తదుపరి వ్యక్తి తెరవకుండా కూడా అది నిరోధిస్తుంది.