సైట్-నుండి-సైట్ VPN యొక్క ప్రతిస్పందన సొరంగం గుండా వెళ్ళడం లేదు
సొరంగాన్ని దాటేసే ప్రతిస్పందన దూరపు వైపు రూటింగ్ నిర్ణయం. హోస్ట్ పట్టిక, సెలెక్టర్లు మరియు rp_filter తనిఖీ చేసి, తర్వాత మార్గం లేదా NAT ఎంచుకోండి.
ఒక ఉదయాన్ని నేను గడిపింది శుభ్రంగా పైకి వచ్చి ట్రాఫిక్ను సరిగ్గా ఒకే దిశలో కదిలించిన ఒక సొరంగంతో: శాఖ ప్రధాన కార్యాలయంలోని ఫైల్ సర్వర్ను చేరుకోగలిగింది, ప్రధాన కార్యాలయం నుండి శాఖలోకి తెరిచిన ప్రతి కనెక్షన్ మొదటి SYN వద్దే మరణించింది. SAలు సక్రియంగా ఉన్నాయి, సొరంగం కౌంటర్లు పెరుగుతున్నాయి, మరియు చేతులు కలపడం ఎప్పుడూ సమస్య కాదు. ప్రతిస్పందన సొరంగం కవర్ చేయని చోటికి రూట్ చేయబడుతోంది, ఆ ఎంపిక దూరపు వైపుకు చెందుతుంది. సైట్-నుండి-సైట్ VPN హోస్ట్ గేట్వేకు అప్పగించిన ప్యాకెట్లను మాత్రమే మోస్తుంది, ప్రతి హోస్ట్ ఆ ఎంపికను విడివిడిగా, ప్రతి దిశలో, తన స్వంత రూటింగ్ పట్టిక నుండి చేస్తుంది.
రెండు దిశలు విడివిడిగా రూట్ చేయబడతాయి
IP సంభాషణ దిశను గుర్తుంచుకోదు. ప్యాకెట్ పంపే ప్రతి హోస్ట్ తన సొంత పొడవైన ప్రిఫిక్స్ శోధనను నడిపి, ఒక తదుపరి హాప్ను ఎంచుకుని నిర్ణయాన్ని మరచిపోతుంది. అభ్యర్థన మరియు ప్రతిస్పందన ఒకే కనెక్షన్కు యాదృచ్ఛికంగా చెందిన రెండు సంబంధం లేని ప్యాకెట్లు, సొరంగం అనేది వాటిలో ఏదైనా ఉపయోగించగల లేదా ఉపయోగించలేని ఒక హాప్. IKE మార్పిడిలో ఏదీ దూర సర్వర్కు మీ సబ్నెట్ను చేరుకునే మార్గాన్ని నేర్పదు; చర్చలు ఏ ప్రిఫిక్స్లను ఎన్క్రిప్ట్ చేయవచ్చో మాత్రమే అంగీకరిస్తాయి.
ఆ ఒప్పందమే రెండవ ద్వారం. strongSwanలో ట్రాఫిక్ సెలెక్టర్లు leftsubnet మరియు rightsubnet, అంగీకరించిన జంటకు వెలుపల మూలం లేదా గమ్యం పడే ప్యాకెట్ ఎన్క్రిప్ట్ చేయబడదు, రూటింగ్ పట్టిక ఏం చెప్పినా. సొరంగంలోకి రూట్ చేయబడి కానీ సెలెక్టర్లలో లేని ప్రిఫిక్స్ నిశ్శబ్ద ఒక-దిశ వైఫల్యం: మార్గం సరిగ్గా కనిపిస్తుంది, ప్యాకెట్ ఇప్పటికీ బహిరంగంగానే బయటకు వెళ్తుంది లేదా విసిరివేయబడుతుంది, charon లాగ్ మాత్రమే ఫిర్యాదు చేస్తుంది.
దూర హోస్ట్కు మీ సొరంగం గురించి ఏమీ తెలియదు
దూర LAN లోపల ప్రతిస్పందన మీ క్లయింట్కు పంపిన సాధారణ ప్యాకెట్. గమ్య హోస్ట్కు ఏ IPsec శీర్షికా కనిపించదు, VPN గేట్వేకు ప్రాధాన్యం ఇవ్వడానికి కారణం లేదు; మీ ప్రిఫిక్స్ను వెతికి, తన డిఫాల్ట్ మార్గం కంటే నిర్దిష్టమైనది ఏదీ కనుగొనలేక దానినే అనుసరిస్తుంది. డిఫాల్ట్ ఏదైనా ప్రధాన ఫైర్వాల్కు సూచిస్తే, ఆ ఫైర్వాల్కు సొరంగంలోకి తిరిగి వెళ్లే మార్గం ఉంటుంది లేదా ఉండదు. లేకపోతే నిశ్శబ్ద డ్రాప్, ICMP unreachable, లేదా ఇంటర్నెట్ వైపు ఉన్న ఇంటర్ఫేస్ నుండి బయటకు వెళ్లి మరణించే ప్రతిస్పందన లభిస్తుంది.
మార్గం ఉన్నా రెండవ ఇంటర్ఫేస్ దీన్ని విరగ్గొట్టడానికి సరిపోతుంది. మరో VLANలో నిర్వహణ లింక్ ఉన్న NAS, బ్యాకప్ uplink ఉన్న సర్వర్, ఒక మూల పరిధిని రెండవ పట్టికకు పంపే విధాన నియమం: వీటిలో ఏదైనా ప్రతిస్పందనను పట్టుకోగలదు. Linuxలో, ip rule show మరియు ip route show table all డిఫాల్ట్ జాబితా దాచే నియమాలను పట్టికలను చూపుతాయి.
ప్రతిస్పందన పంపే యంత్రంలోనే నిర్ణయాన్ని చదవండి
ఏదైనా మార్చే ముందు కెర్నల్ను అడగండి, మూల చిరునామా ఇవ్వండి, ఎందుకంటే మూలం ఆధారిత నియమాలు ప్రతిస్పందనను మారుస్తాయి.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"అవుట్పుట్ బయటకు వెళ్లే ఇంటర్ఫేస్ మరియు తదుపరి హాప్ను పేర్కొంటుంది. ఇంటర్ఫేస్ VPN గేట్వే వైపు ఉన్నది కాకపోతే, మీరు లోపాన్ని కనుగొన్నారు, మిగిలిన పని మార్గం ఎక్కడ ఉండాలో ఎంచుకోవడం. గేట్వే నుండి చేసే ping ఇక్కడ తక్కువ నిరూపిస్తుంది: దూర హోస్ట్ ఉంచగల చిరునామాతో సమాధానం ఇస్తుంది, మీ ల్యాప్టాప్ చిరునామాతో కాదు.
Windowsలో సమానమైనవి నిర్ణయానికి Find-NetRoute -RemoteIPAddress 10.10.5.10, పట్టికకు Get-NetRoute. డిఫాల్ట్ కంటే ఎక్కువ మెట్రిక్ మోసే New-NetRoute తో జోడించిన మార్గం నిశ్శబ్దంగా ఓడిపోతుంది, కాబట్టి ఎంట్రీ కాదు, మెట్రిక్ నిలువు వరుస చదవండి. తర్వాత ప్యాకెట్లతో నిర్ధారించండి: దూర LAN ఇంటర్ఫేస్లో tcpdump -ni any "host 10.10.5.10 and tcp port 445" అభ్యర్థనను చూపుతుంది, సొరంగం వైపు అదే ఫిల్టర్ ప్రతిస్పందన తిరిగి వచ్చిందో లేదో చూపుతుంది. అభ్యర్థన కనిపిస్తోంది కానీ ప్రతిస్పందన లేదు అంటే ప్రతిస్పందన వేరే చోటికి రూట్ అయింది లేదా విసిరివేయబడింది; తప్పు ఇంటర్ఫేస్లో ప్రతిస్పందన మార్గాన్ని తాకే ముందే నిందితుడిని ఇస్తుంది.
సర్వర్ గేట్వే VPN ముగింపు బిందువు కానప్పుడు
చాలా సైట్లు సర్వర్లు మరియు కేంద్రీకరణ పరికరం మధ్య ఫైర్వాల్ పెడతాయి. ఆ ఫైర్వాల్ ప్రతిస్పందనను ముందుకు పంపుతుంది, కాబట్టి మీ క్లయింట్ ప్రిఫిక్స్ కోసం VPN గేట్వే వైపు చూపే మార్గం మరియు రెండు దిశల్లో ఫార్వార్డింగ్ విధానం దానికి అవసరం. స్థితి నిలుపుకునే పరికరాలు దీన్ని మరింత దిగజారుస్తాయి: అభ్యర్థన అది అనుమతించిన LAN హోస్ట్ నుండి ఫైర్వాల్ను దాటింది, ప్రతిస్పందన ఇప్పుడు మరో దిశ నుండి వస్తోంది, కనెక్షన్ ట్రాకింగ్ ఎంట్రీ ఇక మేళవడం లేదు, కాబట్టి ప్యాకెట్ తిరస్కరించబడకుండా చెల్లనిదిగా విసిరివేయబడుతుంది. ట్రాఫిక్ మాయమవుతుండగా విధాన లాగ్ ఖాళీగా కనిపించడానికి కారణం అదే.
గేట్వేకు దాని సొంత రెండవ ఫిల్టర్ ఉంది. Linux యొక్క రివర్స్-పాత్ ఫిల్టరింగ్, అవి వచ్చిన ఇంటర్ఫేస్ ద్వారా మూలం చేరుకోలేని ప్యాకెట్లను విసిరివేస్తుంది, అది చట్టబద్ధమైన అసమాన తిరిగి వెళ్లే మార్గం యొక్క సరైన ఆకారం. strongSwan యొక్క ఫార్వార్డింగ్ మార్గదర్శిని అదే కారణంతో net.ipv4.ip_forward మరియు సడలించిన net.ipv4.conf.all.rp_filter కోరుతుంది. ఏ గేట్వేలోనైనా కఠినమైన విలువ 1 సరైన మార్గాన్ని నిశ్శబ్దంగా విరగ్గొడుతుంది, ఎక్కడ చూడాలో తెలిస్తే nstat -az డ్రాప్లను చూపుతుంది.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
రూట్ చేయండి లేదా అనువదించండి, తర్వాత రెండు దిశల్లో ధృవీకరించండి
రెండు మరమ్మతులు సమానం కావు. మార్గాన్ని జోడించడం క్లయింట్ చిరునామాను తాకకుండా ఉంచుతుంది, కాబట్టి మూల ఆధారిత నియమాలు, ఆడిట్ లాగ్లు మరియు కాల్ చేసినవారిని నమోదు చేసే అప్లికేషన్లు పని చేస్తూనే ఉంటాయి; ధర ఏమిటంటే నిర్ణయం తీసుకునే ప్రతి హాప్కు మార్గం అవసరం, అంటే తప్పు చేయడానికి ఎక్కువ స్థలాలు. దూర గేట్వేపై ముసుగు తిరిగి వెళ్లే మార్గాన్ని ఒక హాప్కు కుదిస్తుంది, ఎందుకంటే ప్రతిస్పందన ఇప్పుడు గేట్వేకే పంపబడుతుంది, మరియు ఏ క్లయింట్ ఏమి చేసిందో దాచుతుంది.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEదాన్ని ఉద్దేశపూర్వకంగా ఎంచుకోండి: క్లయింట్లు గేట్వే చిరునామాగా కనిపించడం మొదలైన వెంటనే, మూల ఆధారిత ACLలు వాటిని వేరు చేయడం ఆపేస్తాయి, ప్రతిస్పందన సొరంగంలోకి తిరిగి రాయబడేలా conntrack మ్యాపింగ్ను పట్టుకోవాలి. సెలెక్టర్లు ఇంకా క్లయింట్ ప్రిఫిక్స్ను మినహాయిస్తే, అభ్యర్థన ఎప్పుడూ సొరంగంలోకి ప్రవేశించనందున NAT ఏమీ మార్చదు.
ఇది సరిచేయబడిందని చెప్పే ముందు నాలుగు విషయాలను వరుసగా నిర్ధారించండి: ప్రతిస్పందన పంపే హోస్ట్పై మార్గం, దాన్ని ముందుకు పంపే ప్రతి హాప్పై మార్గం, రెండు ప్రిఫిక్స్లను కవర్ చేసే సెలెక్టర్లు, మరియు మీరు ఆశించిన మూలంతో ప్రతిస్పందన సొరంగంలోకి ప్రవేశిస్తున్నట్లు చూపే రికార్డింగ్. తర్వాత మరో సైట్ నుండి పరీక్షను పునరావృతం చేయండి. ఒక దిశ దాటడం అనేది సగం-తెరిచిన రూపకల్పన, మరియు రెండవ దిశ సాధారణంగా మీరు ఇప్పుడే సరిచేసిన దాని కంటే వేరే కారణంతో విఫలమవుతుంది.