సైట్-టు-సైట్ VPN ద్వారా IPv6 ప్రిఫిక్స్ డెలిగేషన్: చెక్లిస్ట్

టన్నెల్ పైకి లేపడం సులభమైన సగం. సైట్-టు-సైట్ లింక్ రోజుల తరబడి స్థాపితంగా ఉన్నా, దూరపు LAN లోని ప్రతి హోస్ట్ మౌనాన్ని మాత్రమే తిరిగి పొందుతున్న సందర్భాన్ని నేను చూశాను, ఎందుకంటే ఆ గేట్వే వెనుక ఉన్న డెలిగేట్ చేసిన ప్రిఫిక్స్ ఇంటర్ఫేస్పై కాన్ఫిగర్ చేయబడింది కానీ ఎప్పుడూ టన్నెల్లోకి రూట్ చేయలేదు. టన్నెల్ చిరునామాలు ఆ సమయమంతా పింగ్లకు సమాధానం ఇచ్చాయి, అందుకే ఎవరూ ప్రిఫిక్స్ వైపు చూడలేదు. డెలిగేట్ చేసిన IPv6 ప్రిఫిక్స్ సైట్ VPN ను దాటాల్సి వచ్చినప్పుడు నేను తనిఖీ చేసే క్రమం ఇది: ప్రిఫిక్స్ మ్యాప్, ట్రాఫిక్ సెలెక్టర్లు, ఫార్వార్డింగ్ మరియు ఫైర్వాల్, ఆపై రిటర్న్ పాత్.

టన్నెల్ను తాకే ముందు ప్రిఫిక్స్ మ్యాప్ రాయండి

ప్రిఫిక్స్ డెలిగేషన్ అడిగిన రౌటర్కు ఒక బ్లాక్ను ఇస్తుంది. అది పీర్పై మార్గాన్ని ఇన్స్టాల్ చేయదు, ఆ బ్లాక్ను on-link గా విస్తరించదు, మరియు అడిగిన రౌటర్ వెనుక ఏమి ఉందో దూరపు గేట్వేకు చెప్పదు. ఈ మూడింటిని మీరే కాన్ఫిగర్ చేయాలి, మరియు ఏ కాన్ఫిగ్ ఫైల్ మారే ముందు అవి చిరునామా ప్రణాళికలో ఉండాలి.

ప్రతి సైట్కు డెలిగేట్ చేసిన ప్రిఫిక్స్, LAN లో నిజంగా ఉపయోగించే /64, టన్నెల్ చిరునామాలు మరియు ప్రతి మార్గం యజమానిని నమోదు చేయండి. ప్రొవైడర్ సైట్ A కు 2001:db8:a1::/56 డెలిగేట్ చేస్తారు, అది తన LAN లో 2001:db8:a1:10::/64 అందిస్తుంది; సైట్ B 2001:db8:b2::/64 ను ఉంచుకుంటుంది. సైట్ A ఆ ఒకే /64 మాత్రమే అందిస్తే, రెండు చివరలు మొత్తం /56 కాకుండా 2001:db8:a1:10::/64 ను పేర్కొనాలి.

దాదాపు ప్రతిసారీ రెండు తప్పులు కనిపిస్తాయి. ఒకటి దూరపు ప్రిఫిక్స్ను on-link గా పరిగణించి, బ్రిడ్జ్ చేయడం లేదా టన్నెల్ ఇంటర్ఫేస్పై ఉంచడం, దాంతో గేట్వే చేరుకోలేని హోస్ట్ల కోసం పొరుగు అభ్యర్థనకు సమాధానం ఇస్తుంది. మరొకటి ఒకే /64 కాన్ఫిగర్ చేసి ఉండగా మొత్తం /56 ను ప్రకటించడం: రూట్ పట్టిక బ్లాక్ చేరుకోగలదని చెబుతుంది మరియు చాలా చిరునామాలు నల్ల గుంటలో పడతాయి.

రెండు చివరల ట్రాఫిక్ సెలెక్టర్లను మార్గాలకు సరిపోల్చండి

IKEv2 మరియు WireGuard రెండూ సరిపోలని ట్రాఫిక్ను తిరస్కరిస్తాయి, టన్నెల్ ఇంకా ఆరోగ్యంగా కనిపించేంత నిశ్శబ్దంగా.

strongSwan లో సెలెక్టర్లు స్పష్టంగా ఉంటాయి. సైట్ A లో:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

సైట్ B యొక్క conn రెండు సబ్నెట్లను ప్రతిబింబిస్తుంది. అవి సరిపోలకపోతే, ప్రతిస్పందించేది CHILD_SA ను TS_UNACCEPTABLE తో తిరస్కరిస్తుంది, కాబట్టి IKE_SA పైకి వచ్చినా child SA ఎప్పటికీ పైకి రాదు. రెండు వైపులా కాన్ఫిగర్ చేసిన సబ్నెట్, స్థానిక కెర్నల్ టన్నెల్ వైపు రూట్ చేసే దానికి సమానంగా ఉండాలి.

WireGuard అదే సమాచారాన్ని AllowedIPs లో మోస్తుంది, ఒక మలుపుతో: AllowedIPs స్వీకరించేటప్పుడు మూల ఫిల్టర్ మరియు పంపేటప్పుడు మార్గం. సైట్ B యొక్క సైట్ A కోసం peer నమోదు 2001:db8:a1:10::/64 ను వదిలేస్తే, సైట్ A నుండి వచ్చే ప్యాకెట్లు చెల్లుబాటు handshake పై వచ్చి అనుమతి లేనివిగా విసిరివేయబడతాయి. దాంతో handshake మాత్రమే పదే పదే పునరుద్ధరణ అవుతూ సమాధానం ఎప్పటికీ బయటకు వెళ్లని పరిచిత నమూనా ఏర్పడుతుంది. రెండు చివరలను wg show wg0 allowed-ips తో పోల్చండి. డెలిగేషన్ మారిన ప్రతిసారీ ఆ జాబితాను మళ్లీ తనిఖీ చేయండి; పాత /64 సెషన్ను సజీవంగా ఉంచి కొత్త ప్రిఫిక్స్ను చేరుకోలేనిదిగా చేస్తుంది.

మొదట ఫార్వార్డింగ్, ఫైర్వాల్ మరియు MTU ను మినహాయించండి

మరో లాగ్ లైన్ చదివే ముందు గేట్వేలు అసలు ఫార్వార్డ్ చేస్తున్నాయా అని నిర్ధారించండి. sysctl net.ipv6.conf.all.forwarding రెండింటిలో 1 తిరిగి ఇవ్వాలి, టన్నెల్ మరియు LAN ఇంటర్ఫేస్లకూ వర్తించాలి. ఒక ఉచ్చు కూడా ఉంది: ఫార్వార్డింగ్ ఆన్ అయిన తర్వాత accept_ra=1 ఉన్న ఇంటర్ఫేస్ ప్రొవైడర్ నుండి రౌటర్ ప్రకటనలను స్వీకరించడం ఆపేస్తుంది, కాబట్టి టన్నెల్ లోపల పరిపూర్ణంగా రూట్ చేస్తున్నా యంత్రం తన అప్స్ట్రీమ్ డిఫాల్ట్ మార్గాన్ని కోల్పోవచ్చు. ప్రొవైడర్ RA ఇంకా అవసరమైన చోట accept_ra=2 సెట్ చేయండి.

తర్వాత ఫైర్వాల్ నియమాలు ప్రిఫిక్స్ను రెండు దిశల్లో అనుమతించాలి, ICMPv6 నిలిచి ఉండాలి: పొరుగు కనుగొనడం, packet-too-big మరియు destination-unreachable ఐచ్ఛికం కాదు. వాటిని వదిలేస్తే మార్గ MTU కనుగొనడం పాడై, తెరిచి మొదటి పెద్ద ప్రతిస్పందన వద్ద ఆగిపోయే కనెక్షన్లు వస్తాయి. కనీస నియమాల జోడీ ఇలా ఉంటుంది:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU దీని వెనుక ఉంది. టన్నెల్ ఉపయోగించగల MTU ను 1500 కంటే తక్కువకు తగ్గిస్తుంది, IPv6 ప్రతి లింక్ కనీసం 1280 తీసుకెళ్లాలని కోరుతుంది. చిన్న పింగ్లు దాటుతాయి, SSH సెషన్ పెద్ద పేలుడులో స్తంభిస్తుంది, /proc/net/snmp6 ఎప్పటికీ తిరిగి రాని packet-too-big సందేశాలను చూపుతుంది. టన్నెల్ MTU ను స్పష్టంగా సెట్ చేయండి, లేదా mangle పట్టికలో TCP MSS ను పరిమితం చేయండి, చిన్న MTU ను తెలిపే ICMPv6 తిరిగి రావడానికి అనుమతించండి.

టన్నెల్ చిరునామా కాదు, రిటర్న్ పాత్ను పరీక్షించండి

అత్యధిక సమయం తీసుకునే వైఫల్యం ఏకదిశ రూటింగ్. ప్రతి గేట్వే దూరపు ప్రిఫిక్స్ను టన్నెల్లోకి రూట్ చేస్తుంది, కానీ హోస్ట్లు తమ స్వంత డిఫాల్ట్ గేట్వే ద్వారా సమాధానం ఇస్తాయి, ఎందుకంటే వాటి /64 అక్కడే ఉంది. ప్యాకెట్ను గమ్యానికి చేర్చడం సగం దారి.

రెండు ఆదేశాలు చాలావరకు పరిష్కరిస్తాయి. సైట్ A లో ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ఆ మూలం నుండి వచ్చే ప్రతిస్పందన ఏ ఇంటర్ఫేస్ ఉపయోగిస్తుందో చూపుతుంది; సైట్ B లో అద్దం తనిఖీ చేయండి. తర్వాత గేట్వే కాకుండా హోస్ట్ నుండి ట్రాఫిక్ సృష్టించి రెండు చివరల కౌంటర్లను పోల్చండి.

దూరపు ప్రిఫిక్స్ కోసం పొరుగు అభ్యర్థన టన్నెల్పై కనిపిస్తే, ఆ ప్రిఫిక్స్ ఉండకూడని చోట on-link గా ఉంది; మార్గాలను సర్దుబాటు చేయడానికి ముందు దాన్ని సరిచేయండి. Proxy NDP బ్రిడ్జింగ్ నిజంగా అవసరమైన సందర్భాలను కవర్ చేస్తుంది, మార్గానికి ప్రత్యామ్నాయం కాదు.

ప్రిఫిక్స్ మీ కింద మారుతుందని ప్రణాళిక వేయండి

ప్రిఫిక్స్ డెలిగేషన్ డెలిగేట్ చేసే మరియు అడిగే రౌటర్ల మధ్య లీజు, మరియు పునరుద్ధరణ వేరే బ్లాక్ను తిరిగి ఇవ్వవచ్చు: ప్రొవైడర్ మైగ్రేషన్ తర్వాత మరో /56, లేదా టన్నెల్ ఉన్న కాలం కంటే చిన్న లీజు. పాత ప్రిఫిక్స్ను పేర్కొనే ప్రతి స్థలం ఒక్కసారిగా పాతబడుతుంది: మార్గాలు, సెలెక్టర్లు, AllowedIPs, ఫైర్వాల్ నియమాలు, DNS రికార్డులు మరియు అక్షర చిరునామాలను హార్డ్కోడ్ చేసే ఏ పర్యవేక్షణ అయినా. సందేశ ప్రవాహం RFC 8415 లో ఉంది.

ప్రిఫిక్స్ కదులుతుందని ఆశించే చోట, దానిపై ఆధారపడని అంతర్గత చిరునామా ప్రణాళికను ఉంచి సరిహద్దులో అనువదించండి. NPTv6 స్థితిలేని ఎంపిక మరియు అంతర్గత విధానాన్ని చదవగలిగేలా ఉంచుతుంది, కానీ ఇది ప్రిఫిక్స్ అనువాదం, మాయా పొర కాదు: /64 సరిహద్దులు సరిపోలాలి, చెక్సమ్లు సర్దుబాటు అవుతాయి, అక్షర చిరునామాలను పొందుపరిచే అనువర్తనాలు ఇప్పటికీ విరిగిపోతాయి. ప్రొవైడర్ చిరునామాలను చివర నుండి చివర వరకు ఉంచుకుంటే, లీజు ప్రవర్తన మరియు మార్పు ప్రక్రియను చిరునామా ప్రణాళికలో నమోదు చేయండి.

సమయాన్ని తట్టుకునే పరీక్షతో ముగించండి: ప్రతి LAN లోని అనుమతించిన హోస్ట్ మరో LAN లోని సేవను చేరుకుంటుంది, ప్రతిస్పందన టన్నెల్ ద్వారా తిరిగి వస్తుంది, టన్నెల్ పునఃప్రారంభం మరియు డెలిగేషన్ పునరుద్ధరణ తర్వాత కూడా అదే జోడీ పనిచేస్తుంది. చివరి భాగం విఫలమైతే, రూపకల్పన వారం తట్టుకోలేని స్థితిపై ఆధారపడి ఉంటుంది.