WireGuard లోపల IPIP: ఎవరూ బడ్జెట్లో పెట్టుకోని ఆ అదనపు 20 బైట్లు
IPIP WireGuard లోపల 20 అదనపు బైట్లు ఖర్చు చేస్తుంది. ప్రత్యక్ష టన్నెల్పై ఆగిపోయిన బదిలీకి ఫ్రాగ్మెంటేషన్ను నిందించే ముందు సరైన పొరలో బడ్జెట్ చేయండి.
చిన్న ping లు రోజంతా టన్నెల్ దాటుతాయి, SSH బ్యానర్ వస్తుంది, ఆపై ఫైల్ బదిలీ ప్రారంభమైన క్షణంలో సెషన్ గడ్డకట్టుకుపోతుంది. ఈ నమూనా తప్పు పొరలో లెక్కించిన బైట్ బడ్జెట్ను సూచిస్తుంది, అక్కడ బయటి టన్నెల్ దాని స్వంత ఓవర్హెడ్ కోసం కొలవబడింది మరియు లోపలి దాన్ని ఎవరూ తీసివేయలేదు. WireGuard కు లోపల ఇమిడిన IPIP ప్యాకెట్ మరో IP ప్యాకెట్ మాత్రమే, అందుకే మీరు ఎప్పుడూ కేటాయించని బైట్లను అది వినియోగిస్తుంది. సవరణ అంకగణితం, అది మూడు ఆదేశాలు మరియు ఒక పట్టికలో ఇమిడిపోతుంది.
దాన్ని బయటపెట్టే లక్షణం
ఫ్రాగ్మెంటేషన్ సమస్య తనను తాను పరిమాణంతో ప్రకటించుకుంటుంది, ఎప్పుడూ చిరునామాలతో కాదు. మీ పీర్ ఒక గంట పాటు 56 బైట్ ping కు సమాధానం ఇచ్చి, ఆపై 1400 బైట్ వద్ద నిశ్శబ్దమవుతుంది, టన్నెల్ పైనే ఉంటుంది మరియు ఏ మార్గం మారలేదు. హ్యాండ్షేక్ సరిపోతుంది, మొదటి పూర్తి TCP విండో సరిపోదు, ఆరోగ్యకరంగా కనిపించిన కొన్ని సెకన్ల తర్వాత బదిలీ ఆగిపోతుంది.
ఏదైనా సవరించే ముందు పైకప్పును కొలవండి, ఎందుకంటే కొలవని పైకప్పే మీరు రెండుసార్లు వెంబడించేది. అనుమానిత పరిమాణం కంటే తక్కువలో do-not-fragment బిట్ సెట్ చేసి ఒక ప్రోబ్ పంపండి, ping -M do -s 1000 10.9.0.2, ఆపై చాలా పెద్దదని మీకు ఇప్పటికే తెలిసిన పరిమాణంలో పునరావృతం చేయండి. గమ్యం మారకుండా ఉండగా మలుపు పేలోడ్ పరిమాణాన్ని అనుసరిస్తే, రూటింగ్ తన పని చేస్తోంది మరియు బడ్జెట్ నుండి ఒక హెడర్ లోపించింది.
ప్రతి హెడర్ను ఒకసారి, సరైన పొరలో లెక్కించండి
టన్నెల్ ఇంటర్ఫేస్ నుండి కాదు, మార్గంలోని అతి చిన్న MTU నుండి ప్రారంభించండి, ఎందుకంటే గోడ రెండు చివరల పైన ఉంటుంది. WireGuard IPv4 బయటి రవాణాపై 60 బైట్లు ఖర్చు చేస్తుంది: IP కి 20, UDP కి 8 మరియు తన స్వంత హెడర్కు 32, ఆ రవాణా IPv6 అయితే 80 బైట్లు. 1420 బైట్ wg0 1500 బైట్ మార్గం నిజంగా అందించగల 1440 కంటే కింద 20 బైట్ల సడలింపును ఉంచుతుంది, అందుకే వికీ నుండి కాపీ చేసిన సంఖ్య ఇక్కడ కూడా సరిపోతుంది. మొత్తం స్టాక్ను చిత్రంలో గీయండి, ఎందుకంటే తదుపరిసారి MTU మార్చేవారు లేకుంటే కొత్త గుండ్రని సంఖ్యను ఎంచుకుని మీ బగ్ను వారసత్వంగా పొందుతారు.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
ఐదవ వరుసే బడ్జెట్లు తప్పుపట్టే చోటు, ఎందుకంటే లోపల ఇమిడిన ఇంటర్ఫేస్ మోసే 1400 బైట్లలో అసలు ప్యాకెట్ యొక్క స్వంత 40 బైట్ హెడర్లు ఇప్పటికే ఉన్నాయి. ఆ బైట్లలో 1360 మాత్రమే ఫైల్ చదివే ప్రక్రియకు చేరుతాయి. 1400 ను అప్లికేషన్ పేలోడ్గా పరిగణించండి, ఆ నిలువు వరుస లేని ఏ చిత్రమైనా మిమ్మల్ని అలా ఆహ్వానిస్తుంది, లోపలి పరికరం కదలని గోడ ముందు 40 బైట్లు అధికంగా ఉదారంగా ముగుస్తుంది.
రెండు MTU లను విడివిడిగా సెట్ చేయండి
వాహకం మరియు లోపల ఇమిడిన పరికరం వేర్వేరు వస్తువులు, కాబట్టి ప్రతిదానికి దాని స్వంత విలువ కావాలి. వాటిని ఈ క్రమంలో వర్తించండి, ఎందుకంటే లోపల ఇమిడిన పరికరం వాహకం నుండి ఏమీ వారసత్వంగా పొందదు:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400
గుర్తుంచుకోదగిన నియమం: లోపలి MTU = బయటి MTU - 20, IPIP టన్నెల్ మోసే ప్యాకెట్ IPv4 అయితే, మరియు - 40, లోపలి ప్యాకెట్ ఏ వైపు అయినా IPv6 అయిన వెంటనే, ఎందుకంటే లోపల ఇమిడిన హెడర్ 20 బైట్ల నుండి 40 కి పెరుగుతుంది. ఆ తీసివేతలో మరేదీ రాదు. మీరు 1420 ఎంచుకున్నప్పుడు WireGuard ఓవర్హెడ్ ఇప్పటికే ఖర్చయింది, దాన్ని రెండుసార్లు వసూలు చేయడం పరిపూర్ణంగా పనిచేసి ఎవరూ కొలవనంత కాలం నెమ్మదిగా ఉండే టన్నెల్ను సృష్టిస్తుంది. రెండు పరికరాలు గుండ్రని 1400 మోసే అమరిక ఆ పొరపాటు యొక్క వేలిముద్ర.
లోపల ఇమిడిన ప్యాకెట్ ఏ వైపు IPv6 ఉన్నా పైనున్న ప్రతి సంఖ్య చెల్లదు, కాబట్టి పోలిన సైట్ నుండి సంఖ్యను కాపీ చేయడం బదులు మళ్లీ లెక్కించండి. IPv6 బయటి మార్గంలో లేదా అసలు డేటాగ్రామ్లో కనిపించిన వెంటనే తీసివేయబడే హెడర్లు ఒక్కొక్కటి 40 బైట్లు, పేలోడ్ సంఖ్య సరిగ్గా అంతే తగ్గుతుంది.
మీకు బహుశా అవసరం లేని ఫైర్వాల్ నియమం
రెండు WireGuard పీర్ల మధ్య తీగపై ఉన్న ఏకైక వస్తువు UDP, కాబట్టి ప్రోటోకాల్ 4 కోసం వచ్చే నియమం, RFC 2003 IPv4-లో-IPv4 ఎన్క్యాప్సులేషన్కు ఇచ్చే సంఖ్య, లోపల ఇమిడిన మార్గాన్ని సృష్టించదు, దాన్ని సజీవంగా ఉంచదు. IPIP హెడర్ ఎన్క్రిప్ట్ చేసిన పేలోడ్ లోపల జీవిస్తుంది, అక్కడ ఏ అంచు ఫైర్వాల్ దాన్ని చూడదు. ప్రోటోకాల్ 4 తెరిచినా హోస్ట్కు మరో అనుమతించిన మార్గం తప్ప ఏమీ కొనదు.
అసలు ప్యాకెట్ యొక్క మూలాలు మరియు గమ్యాలను పేర్కొనే విధానం డీక్యాప్సులేషన్ తర్వాత, టన్నెల్ ఇంటర్ఫేస్లపై మరియు రూటింగ్ పట్టికలో ఉంటుంది. దాన్ని అక్కడ ఉంచండి, అంచు నియమం మూసి ఉండవచ్చు.
WireGuard వాస్తవంగా ఏమి ధృవీకరిస్తుంది
AllowedIPs WireGuard మోసే ప్యాకెట్ యొక్క మూలాన్ని నిర్ణయిస్తుంది, అది మోసేది IPIP-ఎన్క్యాప్సులేట్ చేసిన ప్యాకెట్. అనుమతించిన IPIP మూలం, లోపలి హెడర్ మీరు రూట్ చేయాలనుకోని హోస్ట్ను పేర్కొన్నా అంగీకరించబడుతుంది. కాబట్టి అసలు మూలం పీర్ మీ కోసం తనిఖీ చేసినది కాదు, ఆ లోపలి చిరునామా జంటకు డీక్యాప్సులేషన్ తర్వాత దాని స్వంత అమలు కావాలి.
కవచం రూటింగ్ నిర్మాణాన్ని ఇస్తుంది, రెండవ క్రిప్టోగ్రఫీ పొరను కాదు. WireGuard లోపల IPIP ను అదనపు రక్షణ అని పిలవడం వేరే రూపకల్పనను వివరిస్తుంది.
ఒక ping కాదు, నిచ్చెనతో ధృవీకరించండి
మీరు లెక్కించిన సరిహద్దును రెండు వైపులా దాటే పరిమాణాలను పరీక్షించి, ఆపై రెండు పరికరాల గురించి కెర్నల్ ఏమి నమ్ముతుందో నిర్ధారించండి. 1360 బైట్ పేలోడ్ మరియు 40 బైట్ హెడర్లు కలిసి 1400 అయినప్పుడు, కింది మొదటి ప్రతిధ్వని సరిపోతుంది, రెండవది పైకప్పు నుండి ఒక బైట్ ఆవల కూర్చుంటుంది:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0
పైకప్పు కింద శుభ్రంగా దాటడం మరియు దాని పైన మొదటి పరిమాణంలో విఫలం కావడం అంకగణితం మొదటి నుండి చివరి వరకు నిలబడుతుందని అర్థం. తర్వాత మొదట ఆగిన బదిలీని మళ్లీ అమలు చేయండి, ఎందుకంటే కృత్రిమ ప్రోబ్ బడ్జెట్ను నిరూపిస్తుంది మరియు పంపినవారి స్వంత రాత పరిమాణాల గురించి ఏమీ చెప్పదు. మీరు సరిపోతుందని నిరూపించిన పరిమాణంలో కూడా లోపల ఇమిడిన మార్గం విరిగితే, MTU నుండి మరో పది బైట్లు కత్తిరించే ముందు దూరపు చివర డీక్యాప్సులేషన్ మరియు మార్గాలను పరిశీలించండి.