VPN-లో Docker కంటైనర్ చేరుకోలేమా? సబ్నెట్లను పోల్చండి
Docker ఇచ్చే సబ్నెట్ను VPN కూడా క్లెయిమ్ చేస్తుంది. రెండు చిరునామా ప్రణాళికలను పోల్చి, తిరిగి కనెక్ట్ అయిన తర్వాత కూడా నిలిచే పరిష్కారాన్ని ఎంచుకోండి.
కంటైనర్లు ఆఫీస్ LAN-లో సమాధానం ఇస్తాయి, కానీ కంపెనీ VPN కనెక్ట్ అయిన క్షణంలోనే సమాధానం ఇవ్వడం ఆపేస్తాయి. కంటైనర్లో ఏమీ మారలేదు: రీస్టార్ట్ లేదు, ఇమేజ్ అప్డేట్ లేదు, కాన్ఫిగ్ మార్పు లేదు. మారింది హోస్ట్ రూటింగ్ పట్టిక, అందులో టన్నెల్ జోడించిన రూట్ ఇప్పుడు Docker ఇచ్చిన చిరునామాను కవర్ చేస్తుంది. సబ్నెట్ను మార్చే ముందు లేదా VPN మినహాయింపు అడిగే ముందు రెండు చిరునామా ప్రణాళికలను పక్కపక్కన పెట్టండి, ఎందుకంటే ప్రతి పరిష్కారం చాలా భిన్నమైన సమయాన్ని తీసుకుంటుంది.
కాన్ఫిగ్ మార్చే ముందు రూట్ను చదవండి
Docker నిజంగా నిర్మించిన నెట్వర్క్తో ప్రారంభించండి. IPAM బ్లాక్ చిరునామా ప్రణాళిక, సబ్నెట్ ముఖ్యమైన పంక్తి:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose డిఫాల్ట్గా ప్రతి కొత్త ప్రాజెక్ట్కు /16 కేటాయిస్తుంది, కాబట్టి రెండు సేవలు 65,536 చిరునామాల పరిధిలో ఉండగలవు. ఈ వెడల్పే ఓవర్ల్యాప్లు సాధారణంగా ఉండటానికి కారణం: యాదృచ్ఛికంగా ఎంచుకున్న /16 టన్నెల్ ద్వారా మీరు చేరే సైట్ను మింగేయడానికి తగినంత పెద్దది, టన్నెల్ పైకి వచ్చే వరకు ఎవరూ గమనించరు.
తర్వాత ఒక కంటైనర్ చిరునామా కోసం రూట్ ఎంపికను పోల్చండి — ఒకసారి టన్నెల్ ఆఫ్లో ఉన్నప్పుడు, ఒకసారి అది ఆన్లో ఉన్నప్పుడు:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1రెండు రకాల సమాధానాలు వేర్వేరు చోట్లకు తీసుకెళ్తాయి. అవుట్పుట్ tun0, wg0 లేదా మరో టన్నెల్ పరికరాన్ని పేర్కొంటే, VPN ప్రిఫిక్స్ బ్రిడ్జ్ రూట్ కంటే కనీసం అంతే నిర్దిష్టంగా ఉంటుంది, మరియు ప్యాకెట్ ఎప్పటికీ కంటైనర్కు చేరదు. అది ఇంకా బ్రిడ్జ్ను పేర్కొంటే, హోస్ట్ కంటైనర్ను చేరగలదు, మీ లోపం ఫిల్టరింగ్, DNS లేదా ఒక దిశలో మాత్రమే విఫలమయ్యే రిటర్న్ మార్గం.
/16 ఢీకొనడం సులభం ఎందుకు
Docker ప్రైవేట్ పూల్ల నుండి బ్రిడ్జ్ నెట్వర్క్లను తీసుకుంటుంది, డిఫాల్ట్ పూల్ 172.16.0.0/12 బ్లాక్ నుండి /16 ముక్కలుగా వస్తుంది. కార్పొరేట్ నెట్వర్క్లు తరచుగా అదే ప్రైవేట్ స్థలాన్ని ఉపయోగిస్తాయి, రిమోట్ యాక్సెస్ VPN ఆ ప్రిఫిక్స్లను కనెక్ట్ అయ్యే ప్రతి క్లయింట్కు నెట్టివేస్తుంది. రెండు వైపులా 172.18.0.0/16 తమదేనని నమ్మినప్పుడు, ఒకే రూటింగ్ పట్టికలో రెండు విరుద్ధమైన క్లెయిమ్లు ఉంటాయి.
గెలిచేది ప్రిఫిక్స్ పొడవు నిర్ణయిస్తుంది, రూట్ల క్రమం కాదు. 10.0.0.0/8 నెట్టే టన్నెల్ 172.18.0.0/16 బ్రిడ్జ్ రూట్ను ఓడించదు, ఎందుకంటే /8 తక్కువ నిర్దిష్టం. 172.18.0.0/16, లేదా దానిలోని 172.18.5.0/24 నెట్టే టన్నెల్ ఓడిస్తుంది. అందుకే ఒక ల్యాప్టాప్ ఆఫీస్ నెట్వర్క్లో పనిచేసి అదే VPNతో హోటల్ Wi-Fiలో విఫలమవుతుంది: క్లయింట్కు వేర్వేరు ప్రిఫిక్స్లు అందుతాయి.
అదే పట్టిక రెండో దిశను నియంత్రిస్తుంది. 10.8.4.20 వద్ద అంతర్గత హోస్ట్ అవసరమైన కంటైనర్ ప్యాకెట్ను తన బ్రిడ్జ్ గేట్వేకు పంపుతుంది, తర్వాత హోస్ట్ దానిని టన్నెల్లోకి రూట్ చేస్తుంది. హోస్ట్ NAT చేస్తుంది కాబట్టి ఆ మార్గం సాధారణంగా పనిచేస్తుంది, కానీ కార్పొరేట్ వైపు ల్యాప్టాప్ VPN చిరునామాను మాత్రమే అంగీకరించినప్పుడు, లేదా రివర్స్ పాత్ ఫిల్టరింగ్ అసమాన సమాధానాన్ని పడేసినప్పుడు అది విఫలమవుతుంది.
మూడు పరిష్కారాలను పోల్చండి
బయటపడే మార్గాలు మూడే, అవి ఎవరు ఆమోదించాలి మరియు ఒకటి అమలు చేస్తున్నప్పుడు ఏం విరిగిపోతుంది అనే విషయంలో భిన్నంగా ఉంటాయి.
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
టికెట్ లేకుండా పూర్తి చేయగల ఏకైక పరిష్కారం పునర్నంబరింగ్, అందుకే చాలా వ్యాసాలు అక్కడే ఆగిపోతాయి. కొత్త ప్రాజెక్టులో ఇది చవక, కానీ మైగ్రేషన్ సాధనం లేదా నిల్వ చేసిన కనెక్షన్ స్ట్రింగ్ అక్షర చిరునామాను సూచించడం ప్రారంభించాక ఖరీదైనదవుతుంది. YAML సవరించే ముందు ఆ సూచనలను లెక్కించండి, తర్వాత కాదు.
ఓవర్ల్యాప్ మీ కంపెనీకి నిజంగా స్వంతమైన పరిధిలో ఉన్నప్పుడు టన్నెల్ నుండి మినహాయింపు అత్యంత స్పష్టమైన సమాధానం. ఇది అత్యంత నెమ్మదైనది కూడా, మరియు క్లయింట్ ప్రొఫైల్ను మార్చలేని కాంట్రాక్టర్కు ఇది పనికిరాదు. ప్రచురించిన పోర్ట్ లేదా చిన్న రివర్స్ ప్రాక్సీ ఈ వాదనను తప్పిస్తుంది: క్లయింట్ టన్నెల్ ఇప్పటికే సరిగ్గా రూట్ చేసే చిరునామాతో మాట్లాడుతుంది, ఆ పోర్ట్ మాత్రమే చేరుకోగలిగి ఉండాలి.
ఉద్దేశపూర్వకంగా పరిధిని నిర్ణయించండి
ఒక ప్రాజెక్ట్ కోసం, ప్రాజెక్ట్ పంచుకున్న పూల్ నుండి తీసుకోవడం ఆపేలా compose ఫైల్లో సబ్నెట్ను ప్రకటించండి:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24ఆ పరిధిని మీరు వెతుకుతున్నప్పుడు కనుగొన్న ఉదాహరణ నుండి కాదు, మీ జట్టు నిర్వహించే రిజిస్ట్రీ నుండి తీసుకోండి. VPN నెట్టే ప్రిఫిక్స్లు, ప్రజలు పనిచేసే ఇంటి LANలు, అదే హోస్ట్లోని ఇతర కంటైనర్ నెట్వర్క్లతో దాన్ని తనిఖీ చేయండి. తర్వాత పునర్నిర్మాణాన్ని ప్లాన్ చేయండి, ఎందుకంటే ఉన్న నెట్వర్క్ తన పాత సబ్నెట్ను నిలుపుకుంటుంది: docker compose down, తర్వాత up -d. ఎండ్పాయింట్లు జోడించి ఉన్నప్పుడు docker network rm నిరాకరిస్తుంది, ఫైల్లోని ఏదైనా ipv4_address నమోదు కొత్త పరిధిలో ఉండాలి.
Docker తనంతట తాను సృష్టించే నెట్వర్క్ల కోసం, /etc/docker/daemon.jsonలో డీమన్ పూల్ను సెట్ చేయండి:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}ఈ పూల్ డీమన్ పునఃప్రారంభమైన తర్వాత సృష్టించిన నెట్వర్క్లకు వర్తిస్తుంది, ఇప్పటికే ఉన్న బ్రిడ్జ్లు తమ చిరునామాలను నిలుపుకుంటాయి. ఇది సౌకర్యవంతం మరియు మరచిపోవడం సులభం, కాబట్టి ఎవరైనా దాని నెట్వర్క్ను తిరిగి సృష్టించే వరకు పాత ప్రాజెక్ట్ను ఇంకా ఓవర్ల్యాప్లో ఉన్నట్టుగానే పరిగణించండి. Docker యొక్క ఇంజిన్ నెట్వర్కింగ్ డాక్యుమెంటేషన్ సమీక్షలో పూల్ను సమర్థించుకోవాల్సి వస్తే కేటాయింపు నియమాలను వివరిస్తుంది.
Linux బ్రిడ్జ్ మరియు Docker Desktop వేర్వేరుగా విఫలమవుతాయి
Linux హోస్ట్లో, కంటైనర్లు హోస్ట్ నేమ్స్పేస్లోని బ్రిడ్జ్లపై ఉంటాయి. ఒకే పట్టిక అన్నీ నిర్ణయిస్తుంది, కాబట్టి పై పోలికే మొత్తం కథ: బ్రిడ్జ్ రూట్ను చదవండి, టన్నెల్ రూట్ను చదవండి, నిజమైన కంటైనర్ చిరునామాకు ఏది గెలుస్తుందో చూడండి.
Docker Desktop కంటైనర్లను స్వంత NAT ఉన్న VM వెనుక ఉంచుతుంది. హోస్ట్కు కంటైనర్ చిరునామాకు అసలు రూట్ లేదు; ప్రచురించిన పోర్ట్ ద్వారా సేవను చేరుకుంటుంది, సాధారణంగా 127.0.0.1కు బద్ధమై ఉంటుంది. కాబట్టి VPN క్లయింట్ ఎలాంటి సబ్నెట్ ఓవర్ల్యాప్ లేకుండా సేవను పాడు చేయగలదు: VM అంతర్గత పరిధికి రూట్ ఇన్స్టాల్ చేయడం ద్వారా లేదా టన్నెల్ కనెక్ట్ ఉన్నప్పుడు loopback ట్రాఫిక్ను బ్లాక్ చేయడం ద్వారా. హోస్ట్లో ip route get కంటైనర్ చిరునామాకు రూట్ లేదని నివేదిస్తే, అది ఆశించినదే, బగ్ కాదు.
ఆచరణాత్మక పరిణామం మీరు మొదట ఎక్కడ చూస్తారు అనేది. Linuxలో, రూటింగ్ పట్టికతో ప్రారంభించండి. Desktopలో, ప్రచురించిన పోర్ట్ మరియు VPN క్లయింట్ ఫైర్వాల్ నియమాలతో ప్రారంభించి, VM అంతర్గత సబ్నెట్ టన్నెల్ నెట్టే దేనితోనైనా ఢీకొంటుందో లేదో తనిఖీ చేయండి.
టన్నెల్ ఆన్లో ఉండగా ధృవీకరించండి
ఇది పరిష్కరించబడిందని చెప్పే ముందు VPNను రెండుసార్లు మళ్లీ కనెక్ట్ చేయండి, ఎందుకంటే కనెక్ట్ అయినప్పుడు రూట్లను నెట్టి, డిస్కనెక్ట్ అయినప్పుడు వాటిని ఉపసంహరించుకునే ప్రొఫైల్ మొదటి ప్రయత్నం తర్వాత సరిగ్గా కనిపించవచ్చు. తర్వాత క్లయింట్ నిజంగా చేసే తనిఖీలను నడపండి:
- కంటైనర్ నిజమైన చిరునామాను ఉపయోగించి హోస్ట్ నుండి
ip route get. - సేవ స్వయంగా ఆరోగ్యంగా ఉందని నిరూపించడానికి మరో కంటైనర్ నుండి అభ్యర్థన.
- టన్నెల్ ఆన్లో ఉన్నప్పుడు క్లయింట్ నుండి
curl -sv http://127.0.0.1:8080/, తర్వాత LANలోని మెషీన్ నుండి కంటైనర్ చిరునామాకుtraceroute -n. - అభ్యర్థన హోస్ట్కు చేరి సమాధానం మాయమైతే
sysctl net.ipv4.conf.all.rp_filter.
చివరగా, ఎంచుకున్న పరిధిని అది ఎంచుకోవడానికి ఉపయోగించిన అదే రిజిస్ట్రీలో తేదీ మరియు దానిని కలిగి ఉన్న ప్రాజెక్టుతో రాయండి. తదుపరి ఓవర్ల్యాప్ ఎవరూ డాక్యుమెంట్ చేయని ప్రాజెక్ట్ నుండి వస్తుంది, ఏకైక రక్షణ పరిధిని యాదృచ్ఛికంగా కాకుండా ఉద్దేశపూర్వకంగా కేటాయించడమే.