WireGuard హ్యాండ్షేక్ పనిచేస్తుంది కానీ ఇంటర్నెట్ లేదు: ప్యాకెట్ను ట్రేస్ చేయండి
హ్యాండ్షేక్ కీలు మరియు చేరుకోగలిగే సామర్థ్యాన్ని మాత్రమే నిరూపిస్తుంది. AllowedIPs నుండి ఫార్వర్డింగ్, NAT మరియు తిరిగి వచ్చే మార్గం ద్వారా ఒక ప్యాకెట్ను ట్రేస్ చేసి అది ఎక్కడ ఆగుతుందో చూడండి.
సొరంగం అమలులో ఉంది, wg show ఇటీవలి హ్యాండ్షేక్ను నివేదిస్తుంది, మీరు సర్వర్ యొక్క సొరంగ చిరునామాకు ping చేయవచ్చు, మరియు దానికి ఆవల ఏదీ స్పందించదు. మొదటి ఆలోచన కీలను మళ్లీ సృష్టించడం లేదా కాన్ఫిగ్ను మళ్లీ పంచుకోవడం. అది ఇప్పటికే పనిచేస్తుందని నిరూపించబడిన మార్గంలోని ఆ భాగాన్ని మాత్రమే మారుస్తుంది.
పూర్తయిన హ్యాండ్షేక్ రెండు వైపులా కీలపై ఏకీభవిస్తున్నాయి, UDP ముగింపు బిందువును చేరుతుంది, మరియు క్రిప్టో రౌటింగ్ ప్యాకెట్ను అంగీకరిస్తుంది అని చెబుతుంది. ప్యాకెట్ తర్వాత సర్వర్ను విడిచిపోగలదా అనే దాని గురించి ఏమీ చెప్పదు.
అందువల్ల ఊహించడం బదులు ఒక ప్యాకెట్ను ట్రేస్ చేయండి. అది చనిపోగల నాలుగు స్థలాలు ఉన్నాయి, ప్రతి ఒక్కటి వేరే జాడను వదిలిస్తుంది.
హ్యాండ్షేక్ నిజంగా ఏమి నిరూపిస్తుంది
WireGuard అనేది Noise హ్యాండ్షేక్తో సెషన్ను ఏర్పాటు చేసి, తర్వాత భాగస్వామి కోసం ప్యాకెట్లను ఎన్క్రిప్ట్ చేసే UDP ప్రోటోకాల్. wg show కొన్ని సెకన్ల పాత హ్యాండ్షేక్ను మరియు పెరుగుతున్న బదిలీ కౌంటర్ను చూపినప్పుడు, ముగింపు బిందువు, కీలు మరియు భాగస్వామి పబ్లిక్ కీ అన్నీ సరైనవి.
అది నిరూపించనిది: మీ క్లయింట్ ఇంటర్నెట్ వైపు ట్రాఫిక్ను ఇంటర్ఫేస్లోకి పంపుతోందా, సర్వర్ దాన్ని ఫార్వర్డ్ చేయడానికి సిద్ధంగా ఉందా, లేదా ప్రతిస్పందన తిరిగి వచ్చే మార్గాన్ని కనుగొనగలదా అనేది. ఇవి కెర్నల్ రౌటింగ్ మరియు ఫైర్వాల్ నిర్ణయాలు, అవి సొరంగం బయట తీసుకోబడతాయి.
సర్వర్ యొక్క సొరంగ చిరునామాకు ping చేయడం అంత తప్పుదోవ పట్టించే పరీక్ష కావడానికి కారణం అదే. ఆ ప్యాకెట్ సర్వర్కే చిరునామా చేయబడింది, కాబట్టి అది స్థానికంగా ముగుస్తుంది. దానికి ఎప్పుడూ ఫార్వర్డింగ్, ఎప్పుడూ అనువాదం, ఎప్పుడూ ఇంటర్నెట్ నుండి తిరిగి వచ్చే మార్గం అవసరం లేదు.
AllowedIPs ఒక రౌటింగ్ నిర్ణయం
క్లయింట్పై AllowedIPs రెండు పనులు చేస్తుంది. ఏ గమ్య చిరునామాలు ఈ భాగస్వామి సొరంగంలోకి పంపబడతాయో నిర్ణయించే క్రిప్టోకీ రౌటింగ్ పట్టిక ఇది, మరియు భాగస్వామి మీ నుండి అంగీకరించే మూల చిరునామాల జాబితా కూడా ఇది. క్లయింట్ కాన్ఫిగ్లో 10.8.0.0/24 మాత్రమే ఉంటే, పబ్లిక్ గమ్యాలు ఎప్పుడూ ఇంటర్ఫేస్లోకి రావు మరియు మీ సాధారణ డిఫాల్ట్ మార్గం వాటిని సొరంగం బయటకు తీసుకెళ్తుంది. అప్పుడు సొరంగం పరిపూర్ణంగా పనిచేస్తుంది, మీరు కోరుకున్న ఏదీ చేయదు.
కాన్ఫిగ్ ఫైల్ చెప్పేది కాదు, క్లయింట్ నిజంగా ఏమి ఇన్స్టాల్ చేసిందో చూడండి:
wg show wg0 allowed-ipsip route get 1.1.1.1
రెండవ ఆదేశం నిర్ణాయకం. సమాధానం మీ భౌతిక ఇంటర్ఫేస్ మరియు సాధారణ గేట్వేను పేర్కొంటే, ప్యాకెట్ సొరంగం గుండా వెళ్లడం లేదు మరియు సర్వర్ వైపు ఏ మార్పు దాన్ని సరిచేయదు. IPv4 కోసం 0.0.0.0/0 మరియు IPv6 కోసం ::/0 విడివిడిగా జోడించండి; ఒక కుటుంబానికి అన్నింటినీ పట్టుకునే నియమం మరొకదాన్ని దాని అసలు మార్గంలోనే వదిలిస్తుంది, పనిచేసే IPv4 సొరంగానికి మరియు నిలిచిపోయిన IPv6 శోధనకు ఇదే సాధారణ కారణం.
గేట్వేపై ప్యాకెట్ ఎక్కడ చనిపోతుంది
మార్గం సరైనదై ఉండి ప్యాకెట్ ఇప్పటికీ ఎక్కడికీ వెళ్లకపోతే, అది సర్వర్ను చేరి అక్కడే ఆగిపోతుంది. నాలుగు తనిఖీలు చాలా గేట్వేలను కవర్ చేస్తాయి.
ఫార్వర్డింగ్. sysctl net.ipv4.ip_forward 0 తిరిగి ఇవ్వడం క్లాసిక్ సమాధానం, మరియు చాలా పంపిణీలు ఇప్పటికీ డిఫాల్ట్గా 0 వద్ద ఉన్నాయి. అది 1 ఉండాలి, మరియు రీబూట్లో మాయమయ్యే ఆదేశం బదులు sysctl ఫైల్లో శాశ్వతంగా సెట్ చేయాలి. IPv6 ఫార్వర్డింగ్ ప్రత్యేక స్విచ్.
ఫిల్టర్ విధానం. డిఫాల్ట్ drop విధానంతో ఉన్న FORWARD గొలుసు సొరంగ ట్రాఫిక్ను విసిరేస్తుంది, కానీ హోస్ట్కే వెళ్లే ట్రాఫిక్ను అనుమతిస్తుంది, ఇది లక్షణాలతో సరిగ్గా సరిపోతుంది. సేవ్ చేసిన ఫైల్ కాదు, ప్రత్యక్ష నియమ సమాహారాన్ని చదవండి: nft list ruleset లేదా iptables -S.
అనువాదం లేదా రౌటింగ్. ప్రైవేట్ సొరంగ చిరునామాలు ఉపయోగించే క్లయింట్లకు సర్వర్ నిష్క్రమణ ఇంటర్ఫేస్పై మూల NAT లేదా పై నెట్వర్క్ తిరిగి పంపడం తెలిసిన రౌట్ చేయబడిన ప్రిఫిక్స్ అవసరం. రెండింటి మధ్య ఎంపిక చిరునామా ప్రణాళికను అనుసరిస్తుంది. ఇప్పటికే మీ ప్రిఫిక్స్ను తిరిగి రౌట్ చేసే నెట్వర్క్కు MASQUERADE జోడించడం హానికరం కాదు కానీ అర్థరహితం, మార్గం లేని చోట దాన్ని వదిలేయడం ప్రతిస్పందనలను రౌట్ చేయలేని ప్రైవేట్ పరిధికి చిరునామా చేసినట్లు వదిలిస్తుంది.
తిరిగి వచ్చే మార్గం. రౌట్ చేయబడిన నిర్మాణాలలో, పై రౌటర్కు మీ సర్వర్ వైపు చూపే మార్గం అవసరం. ప్రొవైడర్ నెట్వర్క్ కూడా దాన్ని నిరోధించవచ్చు: కొన్ని క్లౌడ్లు ఇన్స్టాన్స్పై మూల మరియు గమ్య తనిఖీని ప్రారంభిస్తాయి, అది మూలం ఇన్స్టాన్స్ సొంత చిరునామా కాని ప్యాకెట్లను నిశ్శబ్దంగా విసిరేస్తుంది, ఆ తనిఖీ నిలిపివేయబడే వరకు.
DNS రౌటింగ్ కంటే భిన్నంగా విఫలమవుతుంది
తెలిసిన చిరునామాకు ప్యాకెట్ మరియు పేరు శోధన రెండు వేర్వేరు వైఫల్యాలు, లోప సందేశాలు వ్యతిరేక దిశల్లో తప్పుదారి పట్టిస్తాయి. ping 1.1.1.1 పనిచేసి బ్రౌజర్ ఏదీ లోడ్ చేయలేకపోతే, మార్గం బాగుంది మరియు పేరు పరిష్కారం లేదు. ping కూడా విఫలమైతే, DNS అప్రస్తుతం మరియు మీరు మునుపటి విభాగానికి తిరిగి వచ్చారు.
wg-quick కాన్ఫిగ్లోని DNS = లైన్ నుండి రిజాల్వర్ను సెట్ చేయగలదు, systemd-resolved ప్రతి లింక్కు దాని సొంత ప్రవర్తనను కలిగి ఉంటుంది. సొరంగం లోపల మాత్రమే చేరుకోగల చిరునామాతో రిజాల్వర్ను భర్తీ చేసే VPN, సొరంగం పడిన క్షణంలో ప్రతి శోధనను విఫలం చేస్తుంది, ఇది సొరంగమే ఇంటర్నెట్ను పాడు చేస్తున్నట్లు కనిపిస్తుంది.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
సాక్ష్యాన్ని ఉత్పత్తి చేసే క్రమం
మొదట క్లయింట్ వైపు తనిఖీని అమలు చేయండి, ఎందుకంటే అది ఒకే ఆదేశం మరియు సగం అవకాశాలను తొలగిస్తుంది. తర్వాత సర్వర్ ఇంటర్నెట్ నిష్క్రమణగా ఉద్దేశించబడిందా అని నిర్ధారించండి; ప్రైవేట్ ప్రాప్యత కోసం నిర్మించిన గేట్వే పబ్లిక్ గమ్యాలు విఫలమైనప్పుడు పాడైనది కాదు.
సర్వర్పై, క్లయింట్ నుండి ping పంపుతున్నప్పుడు ఇంటర్ఫేస్ను గమనించండి: tcpdump -ni wg0 icmp అభ్యర్థనను చూపాలి, tcpdump -ni eth0 icmp అది బయటకు వెళ్తున్నట్లు చూపాలి, అనువదించబడినా కాకపోయినా. అది మొదటిదానిలో కనిపించి రెండవదానిలో ఎప్పుడూ కనిపించకపోతే, ఆగడం సర్వర్లోనే స్థానికం. అది బయటకు వెళ్లి ఎలాంటి ప్రతిస్పందన తిరిగి రాకపోతే, సమస్య పైన ఉంది, అది వేరే సంభాషణ.
చివరగా, సరిదిద్దడం రీబూట్ను తట్టుకునేలా చేయండి. ఫార్వర్డింగ్ sysctl ఫైల్కు, ఫైర్వాల్ నియమాలు వాటిని లోడ్ చేసే సేవకు, క్లయింట్ మార్గాలు ఇంటర్ఫేస్ను లేపే కాన్ఫిగ్కు చెందుతాయి, మీరు మరచిపోయే షెల్కు కాదు. తిరిగి కనెక్ట్ అవ్వండి, అదే రెండు పరీక్షలను పునరావృతం చేయండి మరియు కౌంటర్లు కదులుతున్నాయని నిర్ధారించండి.