నిర్వహించబడే Always On ప్రొఫైల్ ఉన్న పర్యవేక్షణలోని iPhoneలో, ఫోన్ ప్రతి క్రియాశీల IP ఇంటర్ఫేస్కు ఒక సొరంగాన్ని ఉంచుతుంది, కాబట్టి సెల్యులార్ మరియు Wi-Fi రెండూ తమవి పొందుతాయి. తర్వాత సర్వర్ ఒక పరికరానికి రెండు IKE భద్రతా సంఘాలను జాబితా చేస్తుంది, తరచుగా ఒక వర్చువల్ చిరునామాను పంచుకుంటూ, మరియు మొదటి ప్రవృత్తి దాన్ని rekey లూప్ అని పిలిచి టైమర్లను మార్చడం ప్రారంభించడం. ఆ ప్రవృత్తి సాధారణంగా తప్పు. క్రింది దశలను సర్వర్లో సాక్ష్యాలు కనిపించే క్రమంలో చేయండి, మరియు సర్వర్ మీకు ఏ సందర్భం ఉందో చెప్పే వరకు ఫోన్ సెట్టింగ్లను వదిలేయండి.

సర్వర్ ఇప్పటికే ఉన్న రెండు వరుసలతో ప్రారంభించండి

సంఘాలను swanctl --list-sas తో జాబితా చేసి రెండు నమోదులలో నాలుగు ఫీల్డ్లను చదవండి: దూర చిరునామా, ధృవీకరించిన గుర్తింపు, కేటాయించిన వర్చువల్ IP మరియు సృష్టి సమయం. ఒక గుర్తింపు మరియు ఒక వర్చువల్ IPతో రెండు వేర్వేరు బాహ్య చిరునామాలు ఈ ప్రశ్నను ప్రారంభించిన ఆకారం, మరియు ఏదైనా మార్పుకు ముందు దాన్ని రాసుకోవడం విలువైనది. తర్వాత ప్రతి దానికి జోడించిన చైల్డ్ సంఘాలను తనిఖీ చేయండి, ఎందుకంటే గమ్యస్థాన శోధన ఎప్పుడైనా రెండు సొరంగాలను వేరు చేయగలదా అని ట్రాఫిక్ ఎంపికదారులు నిర్ణయిస్తారు. సెకన్లలో కనిపించి మాయమయ్యే జోడీ గంటల తరబడి జీవించే జోడీకి భిన్నమైన జంతువు.

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

మీరు ఏ అతివ్యాప్తిని చూస్తున్నారో నిర్ణయించండి

IKEv2 rekey మరియు make-before-break పునఃధృవీకరణ ఉద్దేశపూర్వకంగా చిన్న అతివ్యాప్తిని సృష్టిస్తాయి, పాత సంఘాన్ని తొలగించే ముందు కొత్తదాన్ని స్థాపించి. సమయ ముద్రలు సందర్భాన్ని నిర్ణయిస్తాయి, ఎందుకంటే కొత్తది కనిపించిన ఒకటి లేదా రెండు సెకన్ల తర్వాత మాయమయ్యే పాత SA తన పని చేస్తున్న పునరుద్ధరణ. స్వతంత్ర ఇంటర్ఫేస్ సొరంగాలు ఎప్పుడూ అలా కనిపించవు, ఎందుకంటే ప్రతి ఒక్కటి తన ఇంటర్ఫేస్ పనిచేస్తున్నంత కాలం ఉంటుంది, మరియు ఒకదాన్ని తొలగించడం మరొకదాన్ని సృష్టించడం నుండి రాదు.

Apple యొక్క నిర్వహించబడే Always On ప్రవర్తన ఇంటర్ఫేస్ ప్రకారం, అందుకే పర్యవేక్షణలోని పరికరం చేతితో సెట్ చేసిన ప్రొఫైల్ కంటే చట్టబద్ధంగా బిజీగా కనిపించవచ్చు. ప్రొవైడర్ యాప్ ఆటో-కనెక్ట్ టోగుల్ అదే విషయాన్ని సూచించదు, సాధారణ on-demand నియమం కూడా సూచించదు. Apple యొక్క అమలు అవలోకనం ఇంటర్ఫేస్ ప్రకారం నమూనాను వివరిస్తుంది; లూప్ అని ఊహించే ముందు మీ రెండు వరుసలను దానితో పోల్చండి. రెండు ఆకారాలు ఒకే సర్వర్ పూల్ నుండి తీసుకుంటాయి, కాబట్టి అతివ్యాప్తి మీ ఏకైక ప్రారంభ సంకేతం.

ఒక వర్చువల్ చిరునామా రెండు సొరంగాలకు ప్రతిస్పందనలను ఎందుకు బద్దలు కొడుతుందో చూడండి

ఫోన్కు ప్రతిస్పందన అంతర్గత చిరునామాకు చిరునామా చేయబడుతుంది, మరియు కెర్నల్ గమ్యం మరియు విధానం ప్రకారం బయటకు వెళ్లే సొరంగాన్ని ఎంచుకుంటుంది, ఫోన్ ఉపయోగించిన ఇంటర్ఫేస్ ప్రకారం కాదు. ఒకే వర్చువల్ IP మరియు సరిపోలే విధానాలతో రెండు ఏకకాల సంఘాలు ప్రతిస్పందన ఏ సెషన్దో చెప్పడానికి మార్గం లేకుండా రూటింగ్ నిర్ణయాన్ని వదిలేస్తాయి. కొన్ని ప్రతిస్పందనలు తప్పు సొరంగాన్ని తీసుకుంటాయి, మరియు ఫోన్ ఒక దిశలో పనిచేసే లేదా Wi-Fi లేచినప్పుడు చనిపోయే కనెక్షన్ను చూపుతుంది. రెండు ఆదేశ అవుట్పుట్లు స్థితిని నిరూపిస్తాయి: swanctl --list-sas రెండు SAలలో ఒకే వర్చువల్ IPని చూపుతుంది, మరియు ip xfrm policy రెండు సమాన ఎంపికదారులను చూపుతుంది.

ఆ అవుట్పుట్ జోడీనే మీరు మార్పు రికార్డులో అతికిస్తారు. ఏదీ ఒంటరిగా ఒప్పించదు, ఎందుకంటే ప్రతి ఒక్కటి విడిగా నమ్మదగినట్లు కనిపించవచ్చు.

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

పూల్ లేదా సమకాలీన నమూనాను మార్చండి, rekey టైమర్ కాదు

swanctl కాన్ఫిగరేషన్లో, ప్రత్యేకత కనెక్షన్పై స్పష్టమైన విధానం: unique = replace కొత్తది స్థాపించినప్పుడు పాత కనెక్షన్ను తొలగిస్తుంది, మరియు unique = keep కొత్తగా వచ్చినవారిని తిరస్కరిస్తుంది. రెండు విలువలు కనెక్షన్ సెట్ చేసేటప్పుడు పనిచేస్తాయి, దానిలోని చైల్డ్ SAలపై కాదు.

connections {
  ios-alwayson {
    unique = replace
  }
}

ఇంటర్ఫేస్ ప్రకారం క్లయింట్కు ఏ విలువ తటస్థం కాదు. keep రెండవ సొరంగాన్ని తిరస్కరించి శుభ్రమైన స్థితి స్క్రీన్ను పునరుద్ధరిస్తుంది మరియు నిర్వహించబడే రూపకల్పనను బద్దలు కొడుతుంది, అయితే replace పాత సొరంగాన్ని కూల్చివేస్తుంది మరియు అది ఎదురు దిశలో అదే రాజీ. రెండు సొరంగాలు నిజంగా అవసరమైతే, పూల్ బ్యాకెండ్ ఒక గుర్తింపుకు వేర్వేరు లీజులను జారీ చేయాలి, మరియు దాని లీజు కీ అభ్యర్థనలను వేరు చేయాలి. స్థిర గుర్తింపు-నుండి-చిరునామా పట్టిక సంతోషంగా అదే చిరునామాను రెండుసార్లు తిరిగి ఇస్తుంది మరియు అసలు సమస్యను ఎక్కువ కాన్ఫిగరేషన్తో పునరుత్పత్తి చేస్తుంది. రెండవ స్థిర మ్యాపింగ్ను జోడించే ముందు బ్యాకెండ్ లీజులను ఎలా కీ చేస్తుందో తనిఖీ చేయండి.

మీరు నిజంగా అమలు చేసే పరివర్తనలను పరీక్షించండి

క్రియాశీల సెషన్తో Wi-Fi పరిధి నుండి బయటకు వెళ్లండి, తర్వాత తిరిగి రండి, మరియు ప్రతిస్పందనలు రెండు దిశలలో వస్తాయో లేదో తనిఖీ చేయండి. దాన్ని రెండుసార్లు చేయండి, ఎందుకంటే రెండవ పరివర్తనలోనే పాత విధానం సాధారణంగా కనిపిస్తుంది. మీరు తెరిచిన కనెక్షన్పై స్పందించే సేవతో పరీక్షించండి, మరియు సొరంగం నిష్క్రియంగా కూర్చోకుండా ట్రాఫిక్ మోస్తున్నప్పుడు బయటకు వెళ్లడాన్ని పునరావృతం చేయండి. పంపగలిగి స్వీకరించలేని ఫోన్ handshake లాగ్లో ఆరోగ్యంగా మరియు బ్రౌజర్లో విరిగినట్లు కనిపిస్తుంది.

ఒక వరుసకు తగ్గించిన స్థితి స్క్రీన్ పనిచేసే రూపకల్పనకు రుజువు కాదు, ఒక సొరంగం వెళ్లిపోయిందని రుజువు మాత్రమే. పరివర్తన గడచే ముందు రెండు దిశలూ పనిచేయాలి. మీరు గమనించినది అతివ్యాప్తి తనిఖీ రెండు అవుట్పుట్లతో పాటు రాయండి, తద్వారా తదుపరి ఇంజనీర్ పునరావృతం చేయడానికి బదులు పోల్చగలరు.

సంబంధిత వ్యాసాలు