రెండు సైట్ల మధ్య ఉన్న VPN ద్వారా IPv6 రూటింగ్

IPv4 మాత్రమే ఉన్న WAN కూడా లోపలి IPv6ని మోసుకెళ్లగలదు. సెలెక్టర్లు, కర్నెల్ రూట్లు, ఫార్వర్డింగ్ మరియు సమాధానాలను నిశ్శబ్దంగా పడవేసే తిరిగి వచ్చే ప్రిఫిక్స్ను గమనించండి.

రెండు సైట్ల మధ్య టనెల్కు IPv6 ప్రిఫిక్స్ జోడించినప్పుడు, చిత్రం సూచించిన విధంగా ప్యాకెట్ ప్రయాణించదు। స్థానిక గేట్వే మొత్తం IPv6 ప్యాకెట్ను తీసుకుని, దాన్ని ఎన్క్రిప్ట్ చేసి, ముందు ఒక బాహ్య IP హెడర్ను పెడుతుంది; దాని చిరునామా కుటుంబం లోపలి కంటెంట్ వల్ల కాదు, చివరి బిందువుల చిరునామాల వల్ల నిర్ణయమవుతుంది। దూర గేట్వే ఆ బాహ్య హెడర్ను తీసి మూల ప్యాకెట్ను తన LANకు పంపుతుంది; అక్కడ అది మళ్లీ సాధారణ IPv6 ప్యాకెట్। బాహ్య టనెల్ మరియు లోపలి ట్రాఫిక్ ఒక కీ, ఒక చివరి జంట మరియు మరేదీ పంచుకోని రెండు వేర్వేరు సంభాషణలు।

రెండు హెడర్లు, రెండు చిరునామా కుటుంబాలు

IPsec టనెల్ మోడ్లో లోపలి IPv6 ప్యాకెట్ ESP హెడర్ వెనుక పేలోడ్ అవుతుంది। ఆ ESP ప్యాకెట్ను మోసే బాహ్య హెడర్ IPv4 లేదా IPv6 కావచ్చు; అది local_addrs మరియు remote_addrsని అనుసరిస్తుంది। WireGuard ఇదే పనిని తక్కువ ఆచారంతో చేస్తుంది: లోపలి ప్యాకెట్ అనేది సహచరుడి చివరి బిందువు వైపు వెళ్లే UDP డేటాగ్రామ్ పేలోడ్। రెండూ లోపలి హెడర్ను తాకకుండా వదిలేస్తాయి; అందుకే దూర పక్షం డీక్యాప్సులేషన్ తర్వాత దాన్ని రూట్ చేయగలదు।

సైట్ల మధ్య మార్గం IPsec NAT ట్రావర్సల్ వాడినప్పుడు UDP 4500ని మాత్రమే చూస్తుంది, లేదా డిఫాల్ట్ WireGuard శ్రోతకు UDP 51820। మార్గంలో ఏ రౌటరైనా IPv4 మాత్రమే కావచ్చు; IPv6 ట్రాఫిక్ అయినా దాటుతుంది, ఎందుకంటే అది ఆ మార్గంలో ఎప్పుడూ IPv6 ప్యాకెట్గా కనిపించదు। అది స్పష్టమైన మొదటి విభజనను ఇస్తుంది: tcpdump -ni eth0 udp port 51820 ఎన్క్రిప్ట్ చేసిన మార్గాన్ని చూపుతుంది, tcpdump -ni wg0 ip6 లోపలి ట్రాఫిక్ను చూపుతుంది। బాహ్య క్యాప్చర్ రద్దీగా, లోపలిది నిశ్శబ్దంగా ఉంటే కర్నెల్ IPv6ని టనెల్లో పెట్టడం లేదన్న అర్థం; అది రూటింగ్ లేదా విధానం, లింక్ స్థితి కాదు।

గేట్వే ఫార్వర్డ్ చేస్తున్నప్పుడు లోపలి Hop Limitని కూడా తగ్గిస్తుంది; అందుకే చివరి బిందువులు IPv6 మార్గంలో రౌటర్లుగా లెక్కించబడతాయి। బాహ్య హాప్ సంఖ్య మరియు లోపలి Hop Limit వేర్వేరుగా కదులుతాయి; దూర గేట్వే వద్ద చనిపోయే ప్యాకెట్ ఫార్వర్డింగ్లో చనిపోయింది, ఎన్క్రిప్షన్లో కాదు।

సెలెక్టర్లు మరియు AllowedIPs అనుమతి జాబితా

IKEv2, child SA ఏ లోపలి ప్రిఫిక్స్లను మోయగలదో చర్చిస్తుంది। strongSwan 5.9 మరియు తర్వాత వాటిని swanctl.confలో రాయడం ఇలా ఉంటుంది:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

local_ts మరియు remote_tsని వదిలేస్తే strongSwan వాటిని తాను ఎంచుకున్న ఇంటర్ఫేస్ సబ్నెట్ల నుండి తీసుకుంటుంది। ద్వంద్వ స్టాక్ హోస్ట్లో ఆ షార్ట్కట్ తరచుగా IPv4 జంటను మాత్రమే ఇస్తుంది: SA పైకి లేస్తుంది, IPv6 ESP కోడ్ను చేరుకునే ముందే తిరస్కరించబడుతుంది। రెండు ప్రిఫిక్స్లను రాయడం SAని వాటిని మోయగలిగేలా చేస్తుంది; start_action = trap మొదటి సరిపోలే ప్యాకెట్ వద్ద దాన్ని పైకి లేపుతుంది।

WireGuardకు రెండు పనులు చేసే ఒకే జాబితా ఉంది। సహచర బ్లాక్లో AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 పంపేటప్పుడు ఇన్స్టాల్ అయ్యే మార్గం మరియు స్వీకరించేటప్పుడు వర్తించే ఫిల్టర్ రెండూ: లోపలి మూలం ఆ సహచరుడి జాబితా బయట పడే డీక్రిప్ట్ అయిన ప్యాకెట్ నిశ్శబ్దంగా పడవేయబడుతుంది। wg-quick ప్రతి ఎంట్రీకి మార్గాన్ని జోడిస్తుంది; అందుకే కింది సహచర బ్లాక్కు వేరే ip -6 route ఆదేశం అవసరం లేదు।

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

రెండు జాబితాలు అద్దంలా ఉండాలి: సైట్ B, సైట్ A ప్రిఫిక్స్ను దూర సెలెక్టర్గా అంగీకరించి తిరిగి రూట్ చేస్తుంది; రెండు దిశలు ఏకీభవిస్తేనే టనెల్ పనిచేస్తుంది। అసమాన జాబితా ఎక్కువ సమయం తీసుకునే లక్షణాన్ని ఇస్తుంది — ఆరోగ్యకరమైన హ్యాండ్షేక్, ఒక వైపు కదిలే కౌంటర్లు, మరియు A నుండి Bకి విజయవంతమైన ping, కానీ B నుండి ఏదీ Aని చేరుకోదు।

ఫార్వర్డింగ్, రూట్లు మరియు తిరిగి వచ్చే ప్రిఫిక్స్

మీరు చెప్పే వరకు Linux IPv6ని ఫార్వర్డ్ చేయదు; సెట్టింగ్ ఇంటర్ఫేస్ కాదు, namespace ప్రకారం:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

రెండవ పంక్తి రూట్ ఆధారిత నమూనాల్లో ప్రజలు మరచిపోయేది। విధాన ఆధారిత IPsec ప్రిఫిక్స్లతో సరిపోలే XFRM విధానాన్ని ఇన్స్టాల్ చేస్తుంది; కానీ vti6 లేదా WireGuard ఉన్న రూట్ ఆధారిత సెటప్కు ఆ పరికరం వైపు చూపే నిజమైన IPv6 మార్గం కావాలి। sysctlని /etc/sysctl.d/ కింద నిలిపి ఉంచండి; లేకపోతే పునఃబూట్ ఫార్వర్డింగ్ను నిశ్శబ్దంగా ఆపేస్తుంది।

ఫార్వర్డింగ్కు తెలుసుకోదగిన దుష్ప్రభావం ఉంది: కర్నెల్ అప్పుడు రౌటర్ ప్రకటనలను పట్టించుకోదు, net.ipv6.conf.<wan>.accept_ra 2 కాకపోతే; అందుకే WAN చిరునామా SLAAC ద్వారా వచ్చే గేట్వే, ఫార్వర్డింగ్ను ఆన్ చేసిన క్షణంలోనే తన డిఫాల్ట్ మార్గాన్ని కోల్పోవచ్చు। అదే ఫైల్లో ఆ ఇంటర్ఫేస్పై accept_ra = 2 సెట్ చేయండి, మార్గం జీవించి ఉంటుంది। సైట్ B కోర్ కూడా టనెల్ గేట్వే నుండి 2001:db8:aa::/48 నేర్చుకోవాలి, స్థిర మార్గం లేదా టనెల్ పైన రూటింగ్ ప్రోటోకాల్ ద్వారా, లేకపోతే సమాధానం B సొంత నెట్వర్క్లోనే చనిపోతుంది।

భంగం స్థానాన్ని గుర్తించే నాలుగు దశల తనిఖీ

ఈ క్రమంలో పని చేయండి మరియు విఫలమయ్యే మొదటి దశలో ఆగండి, ఎందుకంటే ప్రతి తదుపరి దశ మునుపటి వాటిపై ఆధారపడి ఉంటుంది।

  1. సెలెక్టర్లు: swanctl --list-sas child SAపై IPv6 ప్రిఫిక్స్ జంటను చూపాలి, లేదా wg show wg0 allowed-ips దూర ప్రిఫిక్స్ను కొత్త latest-handshakesతో।
  2. కర్నెల్ మార్గం: ip -6 route get 2001:db8:bb::10 టనెల్ పరికరంతో సమాధానం ఇవ్వాలి, WAN ఇంటర్ఫేస్తో కాదు।
  3. లోపలి క్యాప్చర్: tcpdump -ni wg0 ip6 నిజమైన LAN హోస్ట్ల మధ్య ping చేస్తున్నప్పుడు। బయటకు వెళ్లే ప్యాకెట్లు కానీ ఏవీ తిరిగి రాకపోతే B మార్గం లేదా ఫైర్వాల్ వైపు సూచిస్తాయి; ప్యాకెట్లే లేకపోతే దశ 1 లేదా 2 వైపు తిరిగి సూచిస్తుంది।
  4. గమ్యం: B హోస్ట్పై ss -6 -ltn సేవ IPv6పై వినిపిస్తోందని నిర్ధారిస్తుంది; స్థానిక ఫైర్వాల్ కౌంటర్లు ప్యాకెట్ ఆమోదించబడిందా పడవేయబడిందా చూపుతాయి।

MTU అదే రౌండ్లో వస్తుంది। IPv6 రౌటర్లు ఖండన చేయవు; అందుకే మిక్కిలి పెద్ద ప్యాకెట్ పడవేయబడి Packet Too Big పంపిన వారికి తిరిగి వస్తుంది। హ్యాండ్షేక్లు మరియు చిన్న pingలు పనిచేసి, ఫైల్ బదిలీ నిలిచిపోతే, అది దాటే వరకు పేలోడ్ను తగ్గించండి: ping -6 -s 1400 -c 3 2001:db8:bb::10। WireGuard ఇంటర్ఫేస్ల డిఫాల్ట్ MTU 1420 బైట్లు; IPv4 పైన IPsec మరింత తగ్గిస్తుంది, అందుకే లోపలి MTUని సెట్ చేయడం ICMPv6ని పడవేసే ఫైర్వాల్ గుండా మార్గ MTUని కనుగొనాలని ఆశించడం కంటే మేలు।

ఫైర్వాల్ సమస్యల్లా కనిపించే వైఫల్య విధానాలు

అత్యంత సాధారణమైనది ఫైర్వాల్ కాదు: సేవ ::కి బదులుగా 0.0.0.0కి కట్టుబడుతుంది, AAAA రికార్డు ఉంది, మరియు క్లయింట్ IPv6 ద్వారా వేగవంతమైన తిరస్కరణ పొందుతుంది, దాన్ని ద్వంద్వ స్టాక్ బ్రౌజర్ IPv4కి తిరిగి వెళ్లి దాచుతుంది। కొన్ని అనువర్తనాలే విఫలమైతే, నియమ సముదాయాన్ని తాకే ముందు వినిపించే కుటుంబాన్ని తనిఖీ చేయండి।

రెండవది ICMPv6 ఫిల్టరింగ్। Neighbor Discovery మరియు Packet Too Big సాధారణ నిర్వహణలో భాగం, నిర్ధారణలో కాదు; అన్ని ICMPv6ని పడవేసే విధానం, కనెక్ట్ అయ్యి, ధృవీకరించుకుని, తర్వాత చిన్న ప్యాకెట్ కంటే పెద్ద ఏదైనా వద్ద నిలిచిపోయే టనెల్ను సృష్టిస్తుంది। మార్గం ఆధారపడే రకాలను అనుమతించి, పడవేయడం కనిపించేలా కౌంటర్లను ఆన్లో ఉంచండి।

మూడవది టనెల్కు జోడించబడినా, దానిని కలిగి ఉన్న సైట్ చిరునామా ప్రణాళికలో ఎప్పుడూ జోడించని ప్రిఫిక్స్; అందుకే ఏ రౌటరూ దాన్ని ప్రకటించదు, ఏ హోస్టూ దాని నుండి సమాధానం ఇవ్వలేదు। ఒక ప్రిఫిక్స్ మరియు ఒక హోస్ట్ జంటతో ప్రారంభించి, రెండు దిశలను నాలుగు దశలతో నిరూపించి, తర్వాత మిగతావి జోడించండి; పాడైన ప్రిఫిక్స్ పునఃరూపకల్పనకు బదులు కాన్ఫిగరేషన్లో ఒక పంక్తిగానే ఉంటుంది। తెరిచి ఉంచదగిన ఏకైక అధికారిక సూచన RFC 8200 , అది టనెల్ మోసే హెడర్ను నిర్వచిస్తుంది।

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