TUN/TAP: చెల్లని ఆర్గ్యుమెంట్ — OpenVPN ఫ్రేమింగ్ సరిపోలడం లేదు

క్లయింట్ ప్రామాణీకరిస్తుంది, లాగ్ కనెక్ట్ అయిందని చెబుతుంది, ఏ ప్యాకెట్ టన్నెల్ దాటదు. సర్వర్ write to TUN/TAP: Invalid argument (code=22) తో ప్రయత్నాన్ని ముగిస్తుంది, అది డ్రైవర్ లోపంలా కనిపిస్తుంది మరియు సాధారణంగా అలా ఉండదు. రౌటర్లు మరియు చిన్న Linux సర్వర్లలో ఆ లైన్ చాలాసార్లు రెండు చివరలు డేటా ప్యాకెట్లను ఎలా ఫ్రేమ్ చేయాలనే దానిపై ఏకీభవించడం లేదని అర్థం, కాబట్టి కర్నెల్ తనకు ఇచ్చిన డీక్రిప్ట్ చేసిన బఫర్ను తిరస్కరిస్తుంది. ఆ సమయంలో రౌటింగ్ ఇంకా పరీక్షించబడలేదు.

సరైన రౌటింగ్ టేబుల్ మరియు విరిగిన ఫ్రేమింగ్ ఒప్పందం క్లయింట్ వైపు నుండి ఒకేలా కనిపిస్తాయి: కనెక్ట్ అయింది, ఏదీ పని చేయడం లేదు.

టన్నెల్ పైకి వస్తుంది, ఏదీ దాన్ని దాటదు

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

మొదటి లోపం బదులు డేటా-ఛానెల్ సెటప్ చుట్టూ ఉన్న లాగ్ను చదవండి. అంగీకరించిన కంప్రెషన్ మోడ్, dev రకం మరియు పుష్ చేసిన ఎంపికలు అన్నీ ఎక్కువ వెర్బోసిటీలో కనిపిస్తాయి, మరియు మూడు అసమానతల్లో మీకు ఏది ఉందో అవి చెబుతాయి.

కంప్రెషన్ అనేది ఫ్రేమింగ్, బ్యాండ్విడ్త్ కాదు

కంప్రెషన్ ప్రారంభించినప్పుడు, ప్రతి డేటా ప్యాకెట్ ఎలా ఎన్కోడ్ చేయబడిందో వివరించే హెడర్ను మోసుకెళ్తుంది, రెండు చివరలు ఆ హెడర్పై ఏకీభవించాలి. పాత నమూనా కాన్ఫిగరేషన్ నుండి ఇంకా comp-lzo మోసుకెళ్లే సర్వర్, కంప్రెషన్ లైన్ లేని క్లయింట్తో జతచేయబడితే సరిగ్గా ఈ లోపాన్ని ఉత్పత్తి చేస్తుంది: క్లయింట్ ఎప్పుడూ రాయని హెడర్ను సర్వర్ ఆశిస్తుంది. comp-lzo ను compress lz4-v2 తో కలపడం కూడా అదే విధంగా విఫలమవుతుంది, రెండింటినీ కంప్రెషన్ అని పిలిచినా అల్గోరిథమ్లు భిన్నంగా ఉంటాయి. ఆధునిక లింక్లలో ఈ ఎంపిక బ్యాండ్విడ్త్ ఫీచర్ కాదు, ఫ్రేమింగ్ ఒప్పందం.

వెర్షన్ల ప్రవర్తన ఒక ఉచ్చును జోడిస్తుంది. 2.5 సిరీస్ కంప్రెషన్ ఎంపికలకు పాతబడిన హెచ్చరికలను ఇవ్వడం ప్రారంభించింది, 2.6 కంప్రెస్డ్ ప్యాకెట్లను తిరస్కరించడం మరియు డేటాను కేవలం కంప్రెస్ చేయకుండా వదిలేయడం మధ్య గీత గీస్తుంది. కాబట్టి రౌటర్ ఫర్మ్వేర్ అప్డేట్ ఎవరూ టన్నెల్ను సవరించకుండానే ప్రభావవంతమైన ఒప్పందాన్ని మార్చగలదు.

రెండు చివరలను సమలేఖనం చేయండి లేదా రెండింటి నుండి తొలగించండి

ప్రతి కంప్రెషన్ సూచనను లెక్కించండి: సర్వర్ ఫైల్, పుష్ చేసిన ఏవైనా ఎంపికలు, క్లయింట్-నిర్దిష్ట ఫైల్లు మరియు క్లయింట్ ప్రొఫైల్. సర్వర్పై comp-lzo క్లయింట్పై కూడా అదే పదాన్ని కోరుతుంది, adaptive అనేది పాత బిల్డ్లలో బేర్ ఎంపిక సాధారణంగా సూచించే వారసత్వ డిఫాల్ట్. LZO లేదా కంప్రెషన్ లేబుల్ ఉన్న రౌటర్ GUI స్విచ్ కూడా అదే ఎంపికను రాస్తుంది, కాబట్టి అల్గోరిథమ్లను కలపడం బదులు సరిపోలేలా సెట్ చేయండి. పోలిన పేరు సరిపోతుందని భావించకండి.

కంప్రెషన్ అవసరం లేకపోతే, రెండు చివరల నుండి ఉద్దేశపూర్వకంగా తొలగించండి. సర్వర్పై allow-compression no కంప్రెస్డ్ ప్యాకెట్లను తిరస్కరిస్తుంది, కానీ క్లయింట్లు వాటిని అందించడం ఆపిన తర్వాతే; క్లయింట్ ఇంకా కంప్రెషన్ పంపుతున్నప్పుడు దాన్ని వర్తింపజేయడం మరొక దిశలో అసమానతను తిరిగి సృష్టిస్తుంది.

పుష్ మరియు పరికర రకాన్ని తనిఖీ చేయండి

సర్వర్ తన ప్రధాన ఫైల్ నుండి లేదా క్లయింట్-నిర్దిష్ట ఫైల్ నుండి కంప్రెషన్ సూచనను పుష్ చేయగలదు, క్లయింట్ pull-filter తో పుష్ చేసిన ఎంపికలను వదిలివేయగలదు. వెర్బోసిటీ 4 వద్ద ఒక క్లయింట్ను కనెక్ట్ చేయండి, సర్వర్ ప్రకటించినదాన్ని క్లయింట్ అంగీకరించిన దానితో పోల్చి చదవండి, తర్వాత ఏ ఫిల్టర్ దాన్ని తొలగించలేదని నిర్ధారించండి. రెండు వైపులా ఇప్పుడు ఏకీభవించినా లోపం కొనసాగితే, పరికర రకాన్ని చూడండి: ఒక చివర dev tap మరియు మరొక చివర dev tun ఫ్రేమ్లను మార్పిడి చేసుకోలేవు, కర్నెల్ కూడా అదే విధంగా రాయడాన్ని తిరస్కరిస్తుంది.

బ్రిడ్జ్ చేసిన TAP అమరికకు సర్వర్పై నిజమైన బ్రిడ్జ్ అవసరం, వేరే పరికర పేరు మాత్రమే కాదు. ఇంటర్ఫేస్ను బ్రిడ్జ్లో చేర్చకుండా tap0 గా పేరు మార్చడం రాయడాన్ని అంగీకరించి ఎక్కడికీ వెళ్లని పరికరాన్ని సృష్టిస్తుంది.

తర్వాత ఒక క్లయింట్ మరియు ఒక గమ్యస్థానంతో ధృవీకరించండి: సర్వర్ టన్నెల్ చిరునామాకు పింగ్ చేయండి, తర్వాత దాని LANలోని హోస్ట్కు. మొదటిది డేటా ఛానెల్ను, రెండవది ఫార్వార్డింగ్ను నిరూపిస్తుంది.