కిల్ స్విచ్ ఏదైనా ట్రాఫిక్ ప్రవహించే ముందే VPN సర్వర్‌ను నిరోధిస్తుంది
కిల్ స్విచ్ ఏ దశను నిరోధిస్తుంది: ముగింపు బిందువు అన్వేషణ, బయటి మార్గం, తిరిగి వచ్చే దారి మరియు పాత పీర్ మినహాయింపులు — ఊహలకు బదులు కౌంటర్‌లతో.
కిల్ స్విచ్‌లు ప్రజలు ఊహించని దిశలో విఫలమవుతాయి: సొరంగం కింద ఉన్నప్పుడు ట్రాఫిక్‌ను నిరోధించడానికి అవి నిర్మించబడ్డాయి, సొరంగాన్ని నిర్మించే ప్యాకెట్లే ట్రాఫిక్. అదే మొత్తం దోషం. సొరంగం ద్వారా బయటకు వెళ్లని ప్రతిదాన్ని విసిరే నియమాల సమితి దాన్ని పైకి లేపాల్సిన హ్యాండ్‌షేక్‌ను కూడా విసిరిస్తుంది, కాబట్టి క్లయింట్ లూప్‌లో మళ్లీ ప్రయత్నిస్తుంది, లోపం మొదట తనిఖీ చేసే దశకు ఆపాదించబడుతుంది. ఫైర్‌వాల్‌ను విస్తరించే ముందు మూడు దశల్లో ఏది తిరస్కరించబడుతోందో కనుగొనండి: పేరు అన్వేషణ, పీర్‌కు బయటి ప్యాకెట్, లేదా తిరిగి వచ్చే సమాధానం.
సొరంగం మరియు దాని స్వంత రవాణా ఒకదానిపై మరొకటి ఎలా ఆధారపడతాయి
VPN క్లయింట్‌ను ఒకే సాకెట్ మార్గాన్ని పంచుకునే రెండు నెట్‌వర్క్ స్థితులుగా చదవండి. సొరంగం ఉనికిలోకి రాకముందు క్లయింట్ భౌతిక అడాప్టర్‌లో సాకెట్ తెరిచి గుప్తీకరించిన ఫ్రేమ్‌లను పీర్ చిరునామా మరియు పోర్ట్‌కు పంపుతుంది. ఆ మార్పిడి విజయవంతమైన తర్వాతే సొరంగ పరికరాన్ని సృష్టించి మార్గాలను ఇన్స్టాల్ చేస్తుంది. కిల్ స్విచ్ రెండో స్థితి గురించిన విధానం, రెండింటికీ వర్తించేంత విస్తృతంగా రాయబడింది.
ఇంటర్‌ఫేస్ ఆధారిత నియమాలు సాధారణ రూపం: దీని ద్వారా బయటకు వెళ్లేదాన్ని అంగీకరించండి tun0 లేదా wg0, మిగిలిన అవుట్‌పుట్ మార్గాన్ని విసిరేయండి. ఆ రూపం క్లయింట్ స్వంత సర్వర్ కనెక్షన్‌ను మినహాయించలేదు, కాబట్టి సరైన అమలు ఆ మినహాయింపును స్పష్టంగా జోడిస్తుంది, చేతితో నియమాలు రాసేటప్పుడు మీరూ అలాగే చేస్తారు. Windows మరియు macOSలో ప్రతి అనువర్తన నియమాలు ఇంటర్‌ఫేస్‌కు బదులు ప్రక్రియను సరిపోల్చి దీనిలో కొంత భాగాన్ని తప్పించుకుంటాయి, కానీ సొరంగం ఉనికిలోకి రాకముందు ప్రక్రియ కూడా బయటకు వెళ్లాలి.
మూడు దశలు, అవి జరిగే క్రమంలో
మొదటి దశ పరిష్కారం. ప్రొఫైల్ అక్షరార్థ చిరునామాకు బదులు హోస్ట్‌నామ్‌ను నిల్వ చేసినప్పుడు, ఏదైనా పంపే ముందు క్లయింట్‌కు DNS సమాధానం అవసరం. DNSను సొరంగం పరిష్కర్త వైపు మళ్లించే ప్రొఫైల్ ప్రతిష్టంభనను సృష్టిస్తుంది: అన్వేషణ ప్రారంభించాల్సిన సొరంగం ద్వారానే పరిష్కర్తను చేరుకోగలం. సొరంగం వెలుపల పరిష్కరించడం, లేదా ముగింపు బిందువును చిరునామాకు పిన్ చేయడం, ఈ అస్పష్టతను తొలగిస్తుంది.
రెండో దశ బయటి ప్యాకెట్, అది ఈ క్రమంలో మొదట రూటింగ్, తర్వాత ఫైర్‌వాల్ దాటాలి. wireguard-tools WireGuard కోసం దీని రూటింగ్ సగాన్ని తనే నిర్వహిస్తుంది: తన ప్యాకెట్లను గుర్తించి, ఇప్పుడే ఇన్స్టాల్ చేసిన డిఫాల్ట్ మార్గాన్ని దాటవేయడానికి విధాన నియమాన్ని జోడిస్తుంది; wg-quick మాన్యువల్ పేజీ ఆ నియమాన్ని మరియు అది ఉపయోగించే పట్టికను వివరిస్తుంది. ఆ రూటింగ్‌ను చేతితో మళ్లీ నిర్మించండి, లేదా రెండో సాధనం నియమాలను మళ్లీ రాయనివ్వండి, గుర్తించిన ప్యాకెట్లు అవి సృష్టించాల్సిన సొరంగంలోకి తిరిగి పంపబడవచ్చు.
మూడో దశ తిరిగి వచ్చే దారి. సమాధానం లేని హ్యాండ్‌షేక్ బయటకు విసరడానికి సాక్ష్యం కాదు; అది సర్వర్ ఇన్‌బౌండ్ నియమం లేదా మ్యాపింగ్ మరచిన NAT పరికరంతో సమానంగా సరిపోతుంది. క్లయింట్‌ను తాకే ముందు వీటిని వేరు చేయండి.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
క్లయింట్లు గుర్తించిన లక్షణాన్ని నమోదు చేస్తాయి, విఫలమైన దశను కాదు, కాబట్టి పట్టిక సాధారణంగా లాగ్ కంటే వేగంగా ఉంటుంది.
కౌంటర్లు లాగ్ల కంటే వేగంగా నిర్ణయిస్తాయి
Linuxలో, nft list ruleset లేదా iptables -vnL OUTPUT ప్రతి నియమానికి ప్యాకెట్ కౌంటర్‌ను ముద్రిస్తుంది. ఒకసారి కనెక్ట్ అవ్వండి, విఫలం కానివ్వండి, తర్వాత కౌంటర్లను మళ్లీ చదవండి. కౌంటర్ కదిలిన నియమమే హ్యాండ్‌షేక్ తగిలిన నియమం; ఎక్కడా ఏమీ కదలకపోతే, ప్యాకెట్ ఎప్పుడూ ఫైర్‌వాల్‌ను చేరుకోలేదు. నియమాల సమితి తన సొంత హ్యాండ్‌షేక్‌ను విసిరేయడం నేను చూశాను, దాన్ని చెప్పింది కౌంటర్లు మాత్రమే.
ఎప్పుడూ ఫైర్‌వాల్‌ను చేరుకోలేదు మరియు ఎప్పుడూ హోస్ట్ నుండి బయటకు వెళ్లలేదు అనే వాటిని వేరు చేయడానికి ఇంటర్‌ఫేస్‌నే గమనించండి. ip -s link show dev wlan0 పంపిన ప్యాకెట్లను నివేదిస్తుంది, మరియు tcpdump -ni wlan0 udp port 51820 ఫ్రేమ్‌లను చూపిస్తుంది. క్లయింట్ మళ్లీ ప్రయత్నిస్తున్నప్పుడు అది చదునుగా ఉంటే, లోపం netfilter పైన ఉంది: మిస్ అయిన పీర్ మార్గం, ఇంకా లేని పరికరాన్ని సూచించే విధాన నియమం, లేదా క్లయింట్ మింగే సాకెట్ లోపం.
మినహాయింపులను పత్ర చిరునామాలపై పరీక్షించండి, ఉదాహరణకు 203.0.113.10, తప్పు ఇతరుల హోస్ట్‌ను పరిశీలించకుండా.
పాత ముగింపు బిందువు మినహాయింపు సర్వర్ వైఫల్యంగా చదవబడుతుంది
అత్యంత గందరగోళపరిచే సంస్కరణ పీర్ చిరునామా మారిన తర్వాత కనిపిస్తుంది: చలన చిరునామా సేవ దాన్ని తరలించింది, హోస్ట్ మళ్లీ నిర్మించబడింది, లేదా మీ నెట్‌వర్క్ బయటకు వెళ్లే చిరునామా భిన్నంగా ఉంది. మినహాయింపు ఇంకా పాత చిరునామాన్ని పేర్కొంటుంది, కాబట్టి కొత్త చిరునామాకు వెళ్లే ప్యాకెట్లు విసిరేయడం నియమంపై పడతాయి. అదే కాన్ఫిగరేషన్ నిన్న పని చేసింది, అందుకే ప్రజలు సర్వర్ పరిశోధనతో ప్రారంభిస్తారు.
ఫైర్‌వాల్ నియమం లోపల హోస్ట్‌నామ్ మిమ్మల్ని కాపాడదు. nftablesలో నియమాల సమితి లోడ్ అయినప్పుడు పేరు పరిష్కరించబడుతుంది, కాబట్టి ఆ క్షణంలో ఉన్న చిరునామాను అది పిన్ చేసి, అక్షరార్థ చిరునామా లాగా పాతబడిపోతుంది. శాశ్వత పరిష్కారం ముగింపు బిందువు మారినప్పుడు మినహాయింపును నవీకరించి దాన్ని ఇరుకైనదిగా ఉంచడం: ఒక పీర్ చిరునామా, ఒక రవాణా పోర్ట్. చిరునామా మార్పును తట్టుకునేంత విశాలమైన పరిధి సంబంధం లేని ట్రాఫిక్‌ను కూడా బయటకు పంపగలిగేంత విశాలం.
కిల్ స్విచ్ సర్వర్ హోస్ట్‌పై నడిచినప్పుడు
అదే ఆధార్యం మరో చివర ఉంది, అక్కడ దాన్ని మిస్ చేయడం సులభం. మీ VPN సర్వర్‌గా పనిచేసే యంత్రం కిల్ స్విచ్ ఉన్న డెస్క్‌టాప్ క్లయింట్‌ను లేదా ల్యాప్‌టాప్ నుండి కాపీ చేసిన ఫైర్‌వాల్ ప్రొఫైల్‌ను కూడా నడిపిస్తే, దాని విసిరేయడం నియమాలు సొరంగాలను ముగించే సేవకు వర్తిస్తాయి. క్లయింట్ హ్యాండ్‌షేక్‌కు ఇచ్చే సమాధానాలు విసిరేయబడతాయి, కాబట్టి సర్వర్ ఆరోగ్యంగా కనిపిస్తున్నప్పుడు మరియు దాని సొరంగ ఇంటర్‌ఫేస్ ఉపయోగం లేకుండా ఉన్నప్పుడు కూడా ప్రతి క్లయింట్ కనెక్ట్ అవ్వలేదు.
ఆ హోస్ట్‌కు విసిరేయడానికి ముందు మూడు ఇరుకైన అంగీకారాలు కావాలి: భౌతిక ఇంటర్‌ఫేస్‌పై వినిపించే పోర్ట్, డీక్రిప్ట్ చేసిన ట్రాఫిక్ కోసం సొరంగ ఇంటర్‌ఫేస్, మరియు సొరంగం నుండి క్లయింట్లు చేరాల్సిన చోటికి ఫార్వార్డింగ్. ఇన్స్టాల్ చేసిన సమితిని దీనితో చదవండి: nft list ruleset, iptables -S, లేదా pfctl -sr ఏదైనా మార్చే ముందు, మరియు సేవ్ చేసిన నియమాల సమితి రీబూట్‌ను తట్టుకుంటుందని గుర్తుంచుకోండి, కాబట్టి అక్కడి పొరపాటు దాన్ని సృష్టించిన ప్రక్రియ కంటే ఎక్కువ కాలం జీవిస్తుంది.
యంత్రాన్ని మూసి ఉంచే పునరుద్ధరణ క్రమం
ప్రొఫైల్ నుండి బయటకు పని చేయండి. క్లయింట్ ఉపయోగించే పీర్ చిరునామా మరియు పోర్ట్‌ను చదవండి, సొరంగం లేకుండా హోస్ట్‌నామ్ పరిష్కరించబడుతుందని నిర్ధారించండి, తర్వాత భౌతిక అడాప్టర్‌పై మాత్రమే ఆ చిరునామా మరియు పోర్ట్‌కు ఒక మినహాయింపును జోడించండి. మళ్లీ కనెక్ట్ అవ్వండి మరియు పంపే కౌంటర్‌ను గమనించండి; పూర్తయిన హ్యాండ్‌షేక్ రెండో దశ సరిచేయబడిందని సంకేతం.
పరీక్షిస్తున్నప్పుడు మిగిలిన విసిరేయడం విధానాన్ని దాని స్థానంలో ఉంచండి. హానిచేయని తనిఖీ అంటే సంబంధం లేని పత్ర చిరునామాకు కనెక్షన్ ప్రయత్నించి అది ఇంకా సమయం ముగిసి ఆగుతుందని నిర్ధారించడం, ఇది కిల్ స్విచ్ ఆఫ్ కాదు పని చేస్తోందని చూపిస్తుంది. సొరంగం స్థిరమైన తర్వాత మినహాయింపును బిగించండి, మరియు సౌలభ్యం కోసం క్లయింట్ ప్రోగ్రామ్‌కు శాశ్వత అన్నింటికీ అనుమతి వదలకండి.
సొరంగం పైకి వచ్చినా అనువర్తనం ఇంకా విఫలమైతే, మిగిలిన దశలు ఇది కాదు: విభజిత DNS, MTU మరియు ప్రతి అనువర్తన రూటింగ్ ప్రతి ఒక్కటి కనెక్ట్ అయిన సొరంగాన్ని విరిగిన ట్రాఫిక్‌తో ఇస్తాయి, ప్రతి దానికి వేరే మొదటి తనిఖీ ఉంది.