సైట్-టు-సైట్ VPN కు రెండవ సబ్నెట్ జోడించడం: రెండు మార్గాలు
విధాన ఆధారిత టన్నెల్‌లకు రెండు వైపులా సరిపోలే ఎంపికదారులు కావాలి; మార్గ ఆధారిత వాటికి ఒక మార్గం కావాలి. సరైన మార్గం ఎంచుకోండి మరియు ముందుగా తిరిగి వచ్చే మార్గాన్ని సరిచేయండి.
పని చేస్తున్న సైట్-టు-సైట్ టన్నెల్‌కు రెండవ సబ్నెట్ జోడించడం ఒక డిజైన్‌లో ఐదు నిమిషాలు, మరొకదానిలో దాదాపు మధ్యాహ్నమంతా పడుతుంది. మీరు పేర్కొన్న ప్రిఫిక్స్‌లకు టన్నెల్ మార్గాలు ఇన్‌స్టాల్ చేస్తే, మీరు ఒక మార్గం జోడిస్తే ట్రాఫిక్ దాన్ని అనుసరిస్తుంది. ఒక స్థిర ఎంపికదారు జతను బేరమాడుతున్నప్పుడు, రెండు వైపులా సరిపోలే జతపై అంగీకరించే వరకు కొత్త ప్రిఫిక్స్ రక్షణ లేకుండా ఉంటుంది. మూడు విషయాలు నిర్ణయిస్తాయి: ప్రతి వైపు కాన్ఫిగరేషన్ నిజంగా ఏమి వివరిస్తుంది, బేరమాడిన ట్రాఫిక్ చిన్న సరిపోలే జతకు సంకోచిస్తుందా, కొత్త పరిధికి తిరిగి వచ్చే మార్గం ఎవరిది.
స్థితి లేబుల్ కాదు, కర్నెల్ చదవండి
కనెక్ట్ అయిందని నివేదించే టన్నెల్ కనీసం ఒక చైల్డ్ అసోసియేషన్‌ను ఇన్‌స్టాల్ చేసింది, కానీ మీరు అనుకున్నది కాకపోవచ్చు. Linux లో కర్నెల్ ఏమి వర్తిస్తుందో చూపిస్తుంది: ip xfrm policy ఎంపికదారు జతలను జాబితా చేస్తుంది, swanctl --list-sas (లేదా పాత ipsec statusall) ప్రతి దిశలో ట్రాఫిక్ ఎంపికదారులతో సహా రెండు వైపులా ఏమి అంగీకరించారో చూపిస్తుంది. కొత్త ప్రిఫిక్స్ రెండింటిలో లేకపోతే, కాన్ఫిగ్ ఫైల్ ఏమి చెప్పినా అది రక్షణ లేనిది.
దీన్ని మార్గ పట్టికతో పోల్చండి. మార్గ ఆధారిత అమరికలో రక్షిత ప్రిఫిక్స్‌లకు టన్నెల్ పరికరం తదుపరి అడుగు. విధాన ఆధారిత అమరికలో దూర సబ్‌నెట్‌కు ప్రత్యేక మార్గం తరచుగా ఉండదు, డిఫాల్ట్ మార్గం మాత్రమే, ఎందుకంటే పట్టిక కాదు, విధానమే ట్రాఫిక్‌ను ఎంచుకుంటుంది.
విధాన ఆధారితం: రెండు వైపులా కొత్త ప్రిఫిక్స్ జాబితా చేయాలి
strongSwan పదాలలో ఎంపికదారు చైల్డ్ కాన్ఫిగరేషన్‌లోని local_ts మరియు remote_ts లో ఉంటుంది, leftsubnet మరియు rightsubnet వారసులు. కొత్త ప్రిఫిక్స్ రెండు వైపులా అద్దం లాగా కనిపించాలి: సైట్ A స్థానికం అనేదాన్ని సైట్ B దూరం అంటుంది. అసమానత అరుదుగా శుభ్రమైన లోపం ఇస్తుంది. రెండు వైపులా ఖండన వరకు సంకోచిస్తాయి, పాత ప్రిఫిక్స్ పని చేస్తూనే ఉంటుంది, కొత్తది మాత్రమే నిశ్శబ్దంగా విఫలమవుతుంది.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense లేదా OPNsense లో దీని అర్థం కొత్త స్థానిక సబ్‌నెట్‌ను కొత్త దూర సబ్‌నెట్‌తో జతచేసే రెండవ Phase 2 నమోదు, తర్వాత అన్వయం. పాత నమోదును ఉంచండి; భర్తీ చేయడం అసలు సబ్‌నెట్‌ను జోడించకుండా కదిలిస్తుంది. ఇప్పటికే ఉన్న Phase 2 0.0.0.0/0 వంటి సూపర్‌నెట్ లేదా సంక్షిప్త పరిధిని కవర్ చేస్తే, దాని పక్కన సన్నని నమోదు జోడించవద్దు: అతివ్యాప్త ఎంపికదారులు పోటీ విధానాలను ఇన్‌స్టాల్ చేస్తాయి, మూల్యాంకన క్రమమే విజేతను నిర్ణయిస్తుంది.
IKEv1 ప్రతి సబ్నెట్ జతను దాని స్వంత Phase 2 గా చేస్తుంది, ఒక మార్పిడికి ఒక జత తీసుకునే వైపు మిగిలినవి వదిలివేస్తుంది. IKEv2 ఒక చైల్డ్‌లో అనేక ఎంపికదారు జతలను మోసుకెళ్లగలదు, కానీ రెండు అమలులు అంగీకరిస్తే మాత్రమే. swanctl --list-sas నుండి వచ్చే జాబితా సత్యం; మీరు టైప్ చేసినది అభ్యర్థన.
మార్గ ఆధారితం: మార్గమే విధానం
XFRM ఇంటర్‌ఫేస్ లేదా VTI పరికరం మార్గ పట్టిక ప్రకారం ట్రాఫిక్‌ను మోస్తుంది. కొత్త ప్రిఫిక్స్‌ను రెండు సైట్లలో పరికరం వైపు మళ్లించండి, ఇంటర్‌ఫేస్ రూపాంతరానికి కట్టుబడిన స్థితి వర్తిస్తుంది. సమకాలీకరించడానికి ఎంపికదారు జత లేదు, అందుకే సబ్‌నెట్లు పెరిగే కొద్దీ ఈ డిజైన్ మెరుగ్గా స్కేల్ అవుతుంది. strongSwan ఫార్వార్డింగ్ గైడ్ కర్నెల్ వైపు వివరంగా వివరిస్తుంది.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard మరింత ముందుకు వెళుతుంది. AllowedIPs ఒకేసారి క్రిప్టో అనుమతి జాబితా మరియు wg-quick ద్వారా మార్గ పట్టిక నమోదు. ఒక వైపు మాత్రమే ప్రిఫిక్స్ జోడిస్తే హ్యాండ్‌షేక్, బయటకు వెళ్లే ప్యాకెట్‌లు మరియు నిశ్శబ్దం లభిస్తాయి, ఎందుకంటే దూర వైపు తన జాబితాలో లేని మూలం గల ప్యాకెట్‌లను వదిలివేస్తుంది. wg set రూపం మొత్తం జాబితాను భర్తీ చేస్తుంది, కాబట్టి ముందు పని చేసిన ప్రిఫిక్స్‌లను మళ్లీ రాయండి, లేకపోతే వాటిని కత్తిరిస్తారు:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0wg-quick బదులు wg set ఉపయోగించినప్పుడు ఆ రెండవ ఆదేశం ఐచ్ఛికం కాదు. కర్నెల్ కొత్త జాబితాను వెంటనే అంగీకరిస్తుంది, కానీ ఎవరూ దానికి మార్గం జోడించరు, కాబట్టి స్థానికంగా సృష్టించిన ట్రాఫిక్ ఇప్పటికీ డిఫాల్ట్ గేట్‌వే ద్వారానే బయటకు వెళుతుంది. కొత్త WireGuard సబ్నెట్ టన్నెల్ హోస్ట్ నుండి పని చేసి ల్యాప్‌టాప్ నుండి పని చేయకపోవడానికి ఇదే సాధారణ కారణం.
తిరిగి వచ్చే మార్గం టన్నెల్ కంటే ఎక్కువసార్లు విఫలమవుతుంది
కొత్త దూర సబ్‌నెట్‌లోని హోస్ట్‌లు సమాధానాలను VPN గేట్‌వే ద్వారా తిరిగి పంపాలి. ఆ గేట్‌వే వారి డిఫాల్ట్ రౌటర్ కాకపోతే సమాధానం LAN రౌటర్‌కు వెళుతుంది, అది దాన్ని వదిలివేస్తుంది లేదా ప్రైవేట్ మూల చిరునామాతో ఇంటర్నెట్‌కు పంపుతుంది. గేట్‌వే నుండి కాదు, దూర వైపు హోస్ట్ నుండి పరీక్షించండి: Linux లో ip route get 10.30.20.15 లేదా PowerShell లో Find-NetRoute -RemoteIPAddress 10.30.20.15 హోస్ట్ నిజంగా ఉపయోగించే తదుపరి అడుగును చూపిస్తుంది. సమాధానం టన్నెల్ ముగింపు కాకపోతే, అక్కడ కొత్త ప్రిఫిక్స్‌కు స్థిర మార్గం జోడించండి.
తిరిగి వచ్చే మార్గం లేని సైట్‌లో మూల NAT చట్టబద్ధమైన ప్రత్యామ్నాయం, అలాగే చాలా hub-and-spoke అమరికలు ప్రతి సర్వర్‌ను తాకకుండా ఉండే మార్గం. గమ్యం వైపు గేట్‌వేలో కొత్త ప్రిఫిక్స్‌పై కూడా దీన్ని వర్తించండి:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEఖర్చు నిజమైనది. దూర లాగ్‌లు వ్యక్తిగత మూల చిరునామాలను చూపించడం ఆపేస్తాయి, అసలు సబ్నెట్ ఆధారిత ఫైర్వాల్ నియమాలు గేట్‌వేకు ఒకే నియమంగా కలిసిపోతాయి. మార్గం లేకపోవడం వల్ల కాదు, ఉద్దేశపూర్వకంగా ఎంచుకోండి.
ఫైర్‌వాల్‌లు తిరిగి వచ్చే మార్గంలో మరో సగం. జోన్ ఆధారిత పరికరాలు ఇప్పటికే ఉన్న టన్నెల్ ఇంటర్‌ఫేస్ జోన్‌ను కొత్త సబ్‌నెట్‌కు స్వయంచాలకంగా విస్తరించవు, పాత ప్రిఫిక్స్ కోసం రాసిన నియమం సరిపోలదు. IPsec ను నిందించే ముందు కొత్త సబ్‌నెట్‌ను జోన్‌లో లేదా రెండు దిశల నియమ జతలో చేర్చండి.
మూడు ప్రశ్నలతో నిర్ణయించి, తర్వాత ట్రాఫిక్‌తో ధృవీకరించండి
సంక్షిప్త రూపం: వైపు కాన్ఫిగరేషన్ ప్రిఫిక్స్‌లను పేర్కొంటుందా (విధాన ఆధారితం), లేదా ట్రాఫిక్ ఇంటర్‌ఫేస్‌కు మార్గమవుతుందా (మార్గ ఆధారితం)? రెండు చివరలు కొత్త ప్రిఫిక్స్ జాబితా చేస్తున్నాయా? కొత్త సబ్నెట్ నుండి అసలు మూల పరిధికి తిరిగి వెళ్లే మార్గం ఉందా?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
ధృవీకరణ అనేది చాలా మార్పులు చాలా త్వరగా మూసివేయబడే ప్రదేశం. గేట్‌వే నుండి పింగ్ కొద్దిగా నిరూపిస్తుంది, ఎందుకంటే గేట్‌వే తన నుండే పంపుతుంది మరియు హోస్ట్ కంటే భిన్న విధానంతో తరచుగా సరిపోలుతుంది. కొత్త సబ్‌నెట్‌లోని హోస్ట్ నుండి పింగ్ చేయండి, తర్వాత మార్పుకు కారణమైన అప్లికేషన్ నడపండి, స్థితి చిహ్నం కాదు కౌంటర్లను చూడండి.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showవిధాన ఆధారిత టన్నెల్‌లో ip xfrm state కౌంటర్లు రెండు దిశలలో పెరగాలి; చదునైన కౌంటర్లు ప్యాకెట్ మార్గమైంది కానీ ఎంపిక కాలేదని అర్థం. WireGuard లో wg show వైపు వారీగా బదిలీని నివేదిస్తుంది, సున్నా స్వీకరించిన బైట్‌లతో హ్యాండ్‌షేక్ దూర వైపు జాబితాను లేదా దాని తిరిగి వచ్చే మార్గాన్ని సూచిస్తుంది.
ప్రిఫిక్స్, వైపు ఎంపికదారు లేదా మార్గం, తిరిగి వచ్చే మార్గ నిర్ణయం మరియు ఫైర్వాల్ నమోదును మిగిలిన టన్నెల్ జాబితాతో పాటు నమోదు చేసి ముగించండి. తర్వాత ఒక గేట్‌వేను రీబూట్ చేసి మళ్లీ పరీక్షించండి: చేతితో జోడించిన మార్గం మాయమవుతుంది, తదుపరి వ్యక్తి దాన్ని మళ్లీ కనుగొనవలసిన అవసరం లేదు.