macvlan కంటైనర్ VPN క్లయింట్‌కు ప్రత్యుత్తరం ఇవ్వలేని కారణం

VPN ను ముగించి అదే సమయంలో macvlan నెట్‌వర్క్‌లో కంటైనర్‌ను నడిపే Linux హోస్ట్‌ను ఊహించుకోండి. LAN 192.168.60.0/24, కంటైనర్ వద్ద 192.168.60.210 ఉంది, VPN క్లయింట్లు 10.95.0.0/24 నుండి వస్తారు. క్లయింట్ సేవను చేరుకుంటుంది, ప్రత్యుత్తరం ఎప్పటికీ తిరిగి రాదు, హోస్ట్‌పై ప్రతి ఫైర్‌వాల్ నియమం సరైనదిగా కనిపిస్తుంది. ఈ లక్షణాన్ని రెండు వేర్వేరు పరిమితులు సృష్టిస్తాయి, ఒకదాన్ని సరిచేయడం మరొకదాన్ని దాని స్థానంలోనే ఉంచుతుంది.

రెండు పరిమితులు, ఒక లక్షణం

మొదటి పరిమితి వేరుచేయడం: Docker యొక్క macvlan డ్రైవర్ కంటైనర్‌ను పేరెంట్ ఇంటర్‌ఫేస్ ద్వారా తన సొంత హోస్ట్‌తో మాట్లాడటానికి అనుమతించదు. హోస్ట్ స్టాక్ మరియు కంటైనర్ మధ్య ట్రాఫిక్‌కు మార్గం లేదు, హోస్ట్‌పై మార్గాలు ఎలా రాసినా.

రెండవ పరిమితి తిరిగి వచ్చే మార్గం. కంటైనర్ యొక్క డిఫాల్ట్ గేట్‌వే సాధారణంగా LAN రౌటర్, కాబట్టి VPN క్లయింట్‌కు పంపిన ప్రత్యుత్తరం ఆ రౌటర్ ద్వారా బయటకు వెళ్తుంది. రౌటర్‌కు VPN పూల్ వైపు తిరిగి వెళ్లే మార్గం లేకపోతే, ప్రత్యుత్తరం మధ్యలో ఎక్కడో పడవేయబడుతుంది.

క్లయింట్ దృష్టికోణంలో ఈ రెండు వైఫల్యాలు ఒకేలా కనిపిస్తాయి: వచ్చే అభ్యర్థన మరియు ఎప్పటికీ రాని ప్రత్యుత్తరం. వాటికి వేర్వేరు మరమ్మతులు అవసరం, మరియు విస్తృత masquerade నియమం ఏది ఇంకా పాడైందో దాచగలదు. అందుకే మొదటి పరీక్ష మరో ఫైర్‌వాల్ మార్పు కాదు, కంటైనర్ వైపు సంగ్రహణ. అభ్యర్థన అక్కడ ఎప్పటికీ కనిపించకపోతే, వేరుచేయడం పరిమితి పనిచేస్తోంది.

హోస్ట్ వైపు shim ను సన్నగా నిర్మించండి

అదే పేరెంట్‌కు వంతెన మోడ్‌లో అనుసంధానించిన రెండవ macvlan ఇంటర్‌ఫేస్ హోస్ట్ స్టాక్‌కు ఆ LAN విభాగంలో దాని సొంత గుర్తింపును ఇస్తుంది. దాని కోసం DHCP పూల్ వెలుపల మరియు కంటైనర్ పరిధి వెలుపల చిరునామాను కేటాయించి, కంటైనర్‌ను మాత్రమే దాని ద్వారా పంపండి.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

మొదటి ఆదేశం ఇంటర్‌ఫేస్‌ను వంతెన మోడ్‌లో సృష్టిస్తుంది, ఇది ఈ డ్రైవర్ కోసం డాక్యుమెంట్ చేయబడిన డిఫాల్ట్ మరియు హోస్ట్-కంటైనర్ ట్రాఫిక్ కోసం మీకు కావలసిన మోడ్. రెండవది /32 కేటాయిస్తుంది, చిరునామా LAN ప్రీఫిక్స్‌తో ఢీకొనకుండా, నాల్గవది shim ద్వారా కంటైనర్ చిరునామాను మాత్రమే పంపుతుంది.

మొత్తం LAN ను కొత్త ఇంటర్‌ఫేస్ ద్వారా మళ్లించవద్దు. సాధారణ అనుసంధాన మార్గం ఉన్నట్లే ఉంటుంది, హోస్ట్ మార్గం ఉద్దేశపూర్వకంగా సన్నగా ఉంటుంది, ఒక కంటైనర్ మార్గం పొందుతుంది కానీ విభాగంలోని మిగిలిన భాగం ప్రవర్తన మారదు. shim వైపు చూపే డిఫాల్ట్ మార్గం వేరే పరిణామాలతో వేరే రూపకల్పన అవుతుంది. దాన్ని నిర్దిష్టంగా ఉంచండి, నష్ట పరిధి చిన్నగానే ఉంటుంది.

ఈ ఆదేశాలు నడుస్తున్న హోస్ట్‌పై నెట్‌వర్క్ సెట్టింగ్‌లను మారుస్తాయి. పరికరం లేదా నిర్వహిత ప్లాట్‌ఫారమ్‌లో ఆ ప్లాట్‌ఫారమ్ మద్దతిచ్చే కాన్ఫిగరేషన్ విధానాన్ని ఉపయోగించండి, ఎందుకంటే root-shell లో చేసిన ఇంటరాక్టివ్ మార్పు అప్‌గ్రేడ్ తర్వాత ఉండకపోవచ్చు.

మూలం ఎలా సంరక్షించబడుతుందో నిర్ణయించండి

shim ఉన్నప్పుడు కంటైనర్ హోస్ట్‌ను చేరుకోగలదు, ప్రశ్న ఏమిటంటే ప్రత్యుత్తరం ఏ మూల చిరునామాను మోసుకొస్తుంది. అసలు VPN మూలాన్ని సంరక్షించడం స్వచ్ఛమైన నమూనా: కంటైనర్ క్లయింట్ యొక్క నిజమైన చిరునామాను చూస్తుంది, సేవ యొక్క లాగ్‌లు మరియు యాక్సెస్ నియమాలు దాన్ని ఉపయోగించుకోగలవు.

అది పనిచేయడానికి కంటైనర్ యొక్క నెట్‌వర్క్ కాన్ఫిగరేషన్ ఈ మార్గానికి 10.95.0.0/24 యొక్క ట్రాఫిక్‌ను 192.168.60.250 కు దాని గేట్‌వేగా పంపాలి. ఇది కంటైనర్ యొక్క సొంత కాన్ఫిగరేషన్ లోపల మద్దతిచ్చే మార్గం లేదా గేట్‌వే సెట్టింగ్, హోస్ట్ వైపు ఉపాయం కాదు. సెట్టింగ్ అమల్లోకి వచ్చిందని భావించకుండా కంటైనర్ లోపలి నుండి నిర్ధారించుకోండి. ఇంకా LAN రౌటర్ వైపు చూపుతున్న డిఫాల్ట్ గేట్‌వే ప్రత్యుత్తరాలను అదే రంధ్రంలోకి పంపుతూనే ఉంటుంది.

ఆమోదించిన రూపకల్పన బదులుగా VPN మూలాలను దాచినట్లయితే, అనువాదాన్ని సన్నగా పరిమితం చేయండి: నిజమైన VPN పూల్, బయటకు వెళ్లే ఇంటర్‌ఫేస్‌గా shim, మరియు నిర్దిష్ట కంటైనర్ మరియు సేవ.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

shim ను బయటకు వెళ్లే ఇంటర్‌ఫేస్‌గా సరిపోల్చండి, సొరంగం కాదు. సొరంగాన్ని బయటకు వెళ్లే ఇంటర్‌ఫేస్ అని పేర్కొనే నియమం కంటైనర్ వైపు వెళ్లే ప్యాకెట్‌తో సరిపోలదు, ఇలాంటి అమరికల్లో సాధారణంగా ఉండే పొరపాటు అదే. నియమాన్ని పై వాక్యం అంత సన్నగా ఉంచి, పూల్ మారినప్పుడు దాన్ని సమీక్షించండి.

క్లయింట్ నుండి ధృవీకరించండి, హోస్ట్ నుండి కాదు

హోస్ట్ నుండే shim చిరునామాకు కట్టుబడిన అభ్యర్థన shim కంటైనర్‌ను చేరుకోగలదని నిరూపిస్తుంది. కానీ కంటైనర్ సంరక్షించిన 10.95.0.x మూలానికి ట్రాఫిక్‌ను తిరిగి పంపగలదని నిరూపించదు, ఎందుకంటే ఆ పరీక్షలో మూల చిరునామా shim దే.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

మొదటి ఆదేశం హోస్ట్ నుండి కంటైనర్ వరకు భాగాన్ని పరీక్షిస్తుంది, రెండవది నిజమైన VPN క్లయింట్ అభ్యర్థన చేస్తున్నప్పుడు shim ద్వారా వాస్తవంగా ఏమి వెళ్తుందో చూపిస్తుంది. లోపలికి వచ్చే మార్గంలో మూల చిరునామాను మరియు అదే ప్రవాహంతో ప్రత్యుత్తరం కనిపిస్తుందా అని చూడండి.

హోస్ట్‌పై ఫార్వార్డింగ్ ప్రారంభించబడాలి, మరియు ఫార్వార్డింగ్ మార్గానికి సేవ పోర్ట్‌పై VPN పూల్ నుండి shim వైపు అనుమతి మరియు స్థాపించిన ప్రత్యుత్తరాలకు అనుమతి అవసరం. హోస్ట్‌పై INPUT నియమం ఫార్వార్డ్ చేయబడే ట్రాఫిక్‌ను అధికారపరచదు, రూటింగ్ సరైనదిగా కనిపించిన తర్వాత ప్యాకెట్ పడవేయబడటానికి ఇది సాధారణ కారణం.

నిజమైన అప్లికేషన్‌ను నిజమైన ఆధారాలతో నడపండి, తర్వాత అదే కంటైనర్‌పై రెండవ, సంబంధం లేని సేవ మిమ్మల్ని ఇంకా నిరాకరిస్తుందా అని తనిఖీ చేయండి. దాన్ని పని చేయించడానికి ఏకైక మార్గం ప్రతి ఫార్వార్డింగ్ నియమాన్ని తెరవడం అయితే, రూపకల్పన పూర్తి కాలేదు. సేవ ఏ మూల చిరునామాను నమోదు చేసిందో కూడా గమనించండి, ఎందుకంటే ఇకపై దాని సొంత యాక్సెస్ నియమాలు అదే ఉపయోగిస్తాయి.