టనెల్ MTU తగ్గించే వరకు OpenConnect పేజీలు ఎందుకు ఆగిపోతాయి

లాగిన్ విజయవంతమవుతుంది, పోర్టల్ ముందు పేజీ గీయబడుతుంది, ఆ తర్వాత డాష్బోర్డ్ విడ్జెట్ లేదా నివేదిక బ్రౌజర్ వదిలేసే వరకు waiting for host స్థితిలో ఉంటుంది. పబ్లిక్ సైట్లు అన్ని సమయాల్లో సాధారణంగా లోడ్ అవుతాయి, ఏ ఆధారాలు కూడా మారలేదు. పెద్ద ప్రతిస్పందనలు ఆగుతుండగా చిన్నవి రావడం యాక్సెస్ నియమం కాదు, ప్యాకెట్ పరిమాణ పరిమితి సంకేతం. ప్రొఫైల్లో మరేదైనా మార్చే ముందు ఈ పఠనాన్ని నిర్ధారించుకోండి.

పరిమాణ సమస్యను విధాన సమస్య నుండి వేరు చేయండి

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

యంత్రాంగం ఎన్క్యాప్సులేషన్. ప్రతి లోపలి ప్యాకెట్ టనెల్ శీర్షికలను పొందుతుంది, కాబట్టి భౌతిక లింక్లో ఇమిడిన పేలోడ్ ఇక ఇమిడని బయటి ప్యాకెట్ అవుతుంది, do-not-fragment బిట్ ఉన్న ఏదైనా బ్రౌజర్ అర్థం చేసుకోగల ప్రతిస్పందన లేకుండా పడేయబడుతుంది.

do-not-fragment పరీక్షలతో పరిమితిని కొలవండి

ఊహించడం బదులు పరిమితిని కొలవండి. విభజనను తిరస్కరించే పరీక్షలు పంపి, ప్రతిస్పందన వచ్చే వరకు పేలోడ్ను దశలవారీగా తగ్గించండి, ఇలాంటి ఆదేశంతో ప్రారంభించండి: ping -M do -s 1472 host. DF సెట్ ఉన్నప్పుడు విభజన అవసరమని ఫిర్యాదు చేసే ప్రతిస్పందన అంటే విలువ ఇంకా చాలా ఎక్కువగా ఉంది. 1462 వద్ద, ఆ తర్వాత 1452 వద్ద పునరావృతం చేయండి, ప్రతిస్పందించే మొదటి పరిమాణంలో ఆగండి. సంఖ్యను మీరు పరీక్షించిన హోస్ట్తో పాటు రాసి పెట్టుకోండి, ఎందుకంటే సమాధానం ఆ మార్గానికి చెందుతుంది, సాధారణంగా ప్రోటోకాల్కు కాదు.

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

విలువను టనెల్ పరికరంపై వర్తించండి

ఫలితాన్ని Wi-Fi అడాప్టర్పై కాదు, క్లయింట్ సృష్టించిన ఇంటర్ఫేస్పై వర్తించండి. Linux క్లయింట్లో అది ip link set dev tun0 mtu 1300 ఆ తర్వాత విలువ స్వీకరించబడిందని నిర్ధారించడానికి ip link show tun0 . క్లయింట్ నివేదించే పరికర పేరునే ఉపయోగించండి, ఎందుకంటే అది అమలు మరియు టనెల్ ఎలా నిర్మించబడిందనే దానిపై ఆధారపడి మారుతుంది.

టనెల్ MTU తగ్గించడం ప్రతి ప్యాకెట్ మోసే పేలోడ్ను చిన్నదిగా చేస్తుంది, కాబట్టి మొత్తం నిర్గమాంశ కొంచెం తగ్గుతుంది, పెద్ద ప్రతిస్పందనలను నల్ల గుంటలోకి విసరకపోవడం దాని ధర. చిన్న సంఖ్య దానంతటదే సురక్షితం కాదు. బదులుగా భౌతిక అడాప్టర్ను మార్చడం ఆ లింక్పై ప్రతి కనెక్షన్కు హానిని పంచుతుంది, అతి పెద్ద లోపలి ప్యాకెట్లు అంతే పెద్దగా ఉంటాయి.

మొదట క్లయింట్ స్వంత MTU అభ్యర్థనలను ఉపయోగించండి

కాల్ను మీరు నియంత్రించినప్పుడు, క్లయింట్ తర్వాత ప్యాచ్ అవ్వడం బదులు పరిమాణాన్ని అడగవచ్చు. --mtu సర్వర్ నుండి టనెల్ MTU అడుగుతుంది, --base-mtu కింది మార్గం MTUను ప్రకటిస్తుంది, తద్వారా గేట్వే టనెల్ సంఖ్యను పొందగలదు. రెండూ అభ్యర్థనలే, క్లయింట్ మాన్యువల్ గేట్వే వాటిలో ఏదైనా గౌరవిస్తుందని హామీ ఇవ్వదు.

ఆ భేదమే మీ పని క్రమాన్ని నిర్ణయిస్తుంది. మొదట అభ్యర్థనను ప్రయత్నించి అది సృష్టించే ఇంటర్ఫేస్ను పరిశీలించండి, తర్వాత గేట్వే ఎంచుకున్న విలువ ఇంకా ఆగుతుంటే పరికరాన్ని స్థానికంగా సెట్ చేయడానికి తిరిగి వెళ్లండి.

విఫలమైన బదిలీతో ధృవీకరించండి, తర్వాత దాన్ని శాశ్వతం చేయండి

స్థానిక ip link మార్పు క్లయింట్ టనెల్ను తిరిగి నిర్మించే వరకు ఉంటుంది, అది తదుపరి మళ్లీ కనెక్షన్ లేదా పునఃప్రారంభంలో జరుగుతుంది. విలువను కనెక్షన్ ప్రారంభమయ్యే చోట ఉంచండి: క్లయింట్ను నడిపి తర్వాత పరికరాన్ని సర్దుబాటు చేసే ర్యాపర్, ExecStartPost దశతో systemd యూనిట్, లేదా గేట్వే అంగీకరించినప్పుడు క్లయింట్ ఎంపిక. ప్రొఫైల్ పక్కన వెర్షన్ నియంత్రణలో ఉంచండి, తదుపరి వ్యక్తి సంఖ్య ఎందుకు అక్కడ ఉందో చూడగలరు.

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

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