TCP రీసెట్ మీ VPN బ్లాక్ అవుతోందని నిరూపించదు

క్లయింట్ లాగ్‌లో “కనెక్షన్ రీసెట్ చేయబడింది, మళ్లీ ప్రారంభమవుతోంది” కనిపిస్తుంది, మరియు తీర్మానం సాక్ష్యం కంటే ముందే వస్తుంది. నెట్‌వర్క్ VPNను బ్లాక్ చేస్తోంది, లేదా సర్టిఫికేట్ తప్పు, లేదా ఒక నిర్దిష్ట దేశం జోక్యం చేసుకుంటోంది అని ఎవరో నిర్ణయిస్తారు. రీసెట్ అనేది కనెక్షన్‌ను ముగించే TCP ప్యాకెట్, మరియు లాగ్ లైన్ మీ క్లయింట్‌కు ఒకటి లభించిందని నమోదు చేస్తుంది. అది పంపిన పరికరాన్ని లేదా కారణాన్ని పేర్కొనదు.

రీసెట్ ఒక ప్యాకెట్, తీర్పు కాదు

TCP రీసెట్ ప్రాసెసింగ్‌ను నిర్వచిస్తుంది: RST ఫ్లాగ్ ఉన్న సెగ్మెంట్ కనెక్షన్‌ను వెంటనే ముగిస్తుంది. గ్రహీత చర్చలు చేయదు, మళ్లీ ప్రయత్నించదు, ఎందుకు అని అడగదు. అది రీసెట్‌ను నివేదించి ముందుకు సాగుతుంది.

క్లయింట్‌కు తెలిసింది అంతే. RST సర్వర్, ప్రాక్సీ, ఫైర్‌వాల్ లేదా స్థితిని కోల్పోయిన లోడ్ బ్యాలెన్సర్ నుండి రావచ్చు.

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

ఏ కనెక్షన్ రీసెట్ చేయబడిందో నిర్ధారించండి

మొదట సక్రియ ప్రొఫైల్ నిజంగా TCP ఉపయోగిస్తుందో లేదో తనిఖీ చేయండి. UDP టన్నెల్‌పై రీసెట్‌కు అర్థం లేదు, మరియు HTTP ప్రాక్సీ లాగ్ VPN కంటే వేరే TCP భాగానికి సంబంధించి ఉండవచ్చు.

గమ్యస్థానం, పోర్ట్, ప్రయత్న సమయం మరియు క్లయింట్ చేరుకున్న దశను నమోదు చేయండి.

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

మార్గం యొక్క రెండు చివరలను పోల్చండి

మీరు సర్వర్‌ను నిర్వహిస్తే, అదే ప్రయత్నం కోసం దాని సంఘటనలను పోల్చండి. అది కనెక్షన్‌ను అంగీకరించిందా? ఉద్దేశపూర్వకంగా మూసివేసిందా? ఒక ప్రతిస్పందన ఒక సరిహద్దును విడిచి తదుపరిదానికి ఎప్పుడూ చేరలేదా?

వీలైతే క్లయింట్ మరియు సర్వర్ రెండింటిలోనూ క్యాప్చర్ చేయండి. క్లయింట్‌లో కనిపించి సర్వర్‌లో కనిపించని రీసెట్ సర్వర్‌లో పుట్టలేదు.

రెండు దిశలలో RST సెగ్మెంట్లపై శ్రద్ధ వహించండి:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

నియంత్రిత పోలికతో సంకుచితం చేయండి

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

ఇది ఇంకా ఒక నిర్దిష్ట మధ్యవర్తి పరికరాన్ని గుర్తించదు. ఇది పరిధిని ఒక మార్గానికి సంకుచితం చేస్తుంది, ఇది ఉపయోగకరమైన మరియు నిజాయితీ ఫలితం.

“ఈ మార్గం విఫలమవుతుంది” మరియు “ఈ పేరున్న పాత్రధారి దాన్ని కలిగించింది” మధ్య భేదాన్ని నిలుపుకోండి. మొదటిది పరీక్షించదగినది; రెండవది సాధారణంగా ఒక క్లయింట్ నుండి కాదు.

నమ్మక సెట్టింగ్‌లను మార్చకుండా సరిదిద్దడాన్ని తనిఖీ చేయండి

TLS ధృవీకరణను నిలిపివేయవద్దు, ఆధారాలను మళ్లీ సృష్టించవద్దు, మరియు ఒక రీసెట్ లైన్ ఆధారంగా బ్లాకింగ్ విధానాన్ని ప్రకటించవద్దు. ఈ మార్పులలో ప్రతిదీ పరీక్షించబడుతున్న వ్యవస్థను మారుస్తుంది మరియు తదుపరి పోలికను అర్థహీనం చేస్తుంది.

గుర్తించిన భాగాన్ని దాని యజమాని ద్వారా సరిదిద్ది, తర్వాత అదే ప్రొఫైల్ మరియు అదే పరిశీలనను పునరావృతం చేయండి:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

ఉపయోగకరమైన ఫలితం మెరుగ్గా స్థానికీకరించిన వైఫల్యం, మరింత విశ్వాసంగల కథ కాదు. ప్రాక్సీ సరిదిద్దిన తర్వాత రీసెట్ మాయమైతే మీకు కారణం ఉంది. అది మరో దశకు మారితే మార్గం గురించి ఏదో నేర్చుకున్నారు. ఏదేమైనా, సాక్ష్యం రెండవ వ్యక్తి పఠనాన్ని తట్టుకోవాలి. మీరు గమనించినది రాయండి, తీర్మానించినది కాదు.