OpenVPN వెనుక Docker మరియు VM ట్రాఫిక్: మార్గమా లేక పునఃసంఖ్యాయా?

హోస్ట్ సొరంగం ద్వారా బ్రౌజ్ చేస్తుంది, పక్కనున్న కంటైనర్ ఏదీ చేరుకోలేదు. తన స్వంత VPN క్లయింట్ను నడిపే కంటైనర్ నుండి పోర్టును ప్రచురించడం మరింత దారుణం: అభ్యర్థన వస్తుంది, ప్రత్యుత్తరం ఎప్పటికీ బయటకు వెళ్లదు. రెండూ హోస్ట్పై రూటింగ్ నిర్ణయాలు, Docker కేవలం సమాచారం మోసేది మాత్రమే.

ఈ రెండింటిలో ఏది అనేది మూడు ప్రశ్నలు నిర్ణయిస్తాయి, దానికి సుమారు ఒక నిమిషం పడుతుంది.

ఒకేలా కనిపించే రెండు వైఫల్యాలు

మొదటిది తిరిగి వచ్చే మార్గం సమస్య. ప్రచురించిన పోర్టు కంటైనర్కు అనువదించబడుతుంది, అభ్యర్థన వస్తుంది, ప్రత్యుత్తరం హోస్ట్ యొక్క డిఫాల్ట్ మార్గం ద్వారా పంపబడుతుంది, దాన్ని OpenVPN క్లయింట్ tun0 వైపు తిప్పింది. ప్రత్యుత్తరం దూరపు సహచరుడు ఊహించని చిరునామా నుండి బయటకు వెళ్లి, పడవేయబడుతుంది. రెండవది పూర్వపద ఢీకొనడం: Docker యొక్క డిఫాల్ట్ వంతెన 172.17.0.0/16 కలిగి ఉంది, కార్పొరేట్ సొరంగం అదే పరిధిని నెట్టుతుంది.

ఒకటి రూటింగ్ పట్టికతో సరిచేయబడుతుంది, మరొకటి వంతెనను పునఃసంఖ్య చేయడం ద్వారా. ఏది ఏదో తెలుసుకోకముందే సవరించడం పని చేస్తున్న కంటైనర్ను పాడు చేసే మార్గం.

మూడు ప్రశ్నలతో నిర్ణయించండి

ప్రశ్న ఒకటి: VPN ఆపినప్పుడు వైఫల్యం మాయమవుతుందా? సొరంగం ఆఫ్లో ఉన్నప్పుడు అన్నీ పని చేస్తే, తిరిగి వచ్చే మార్గాన్ని అనుమానించండి. ప్రశ్న రెండు: ip route show table all అదే పూర్వపదాన్ని రెండుసార్లు జాబితా చేస్తుందా, ఒకసారి వంతెనపై మరియు ఒకసారి tun0 పై? అదే ఢీకొనడం. ప్రశ్న మూడు: ప్రభావిత చిరునామా కంటైనరా, NAT అతిథా లేక వంతెన చేసిన అతిథా?

మూడవ ప్రశ్న ముఖ్యం ఎందుకంటే ప్రతి దానికి వేరే సరైన పరిష్కారం ఉంటుంది, కంటైనర్ పరిష్కారాన్ని libvirt అతిథికి వర్తింపజేయడం ఒక సాయంత్రాన్ని వృథా చేస్తుంది.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

తిరిగి వచ్చే మార్గం: ఒక మూల చిరునామా కోసం పట్టిక

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

మూలం ఆ చిరునామా అయిన ప్రతి ప్యాకెట్ మొదట పట్టిక 10 చూస్తుంది, పట్టిక 10 దాన్ని సొరంగానికి బదులు వంతెన గేట్వేకు పంపుతుంది.

దీనితో నిర్ధారించండి: ip route get 1.1.1.1 from 172.22.0.3. ప్రత్యుత్తరంలో వంతెన ఇంటర్ఫేస్ ఉండాలి, tun0 కాదు. ఈ విధంగా జోడించిన నియమాలు రీబూట్లో మాయమవుతాయి, కాబట్టి వాటిని కంటైనర్ను కలిగి ఉన్న unit లేదా నెట్వర్క్ హుక్లో ఉంచండి.

అదే నమూనా WireGuard కంటైనర్కు కూడా పని చేస్తుంది, అక్కడ ప్రత్యుత్తర మార్గానికి కూడా స్పష్టమైన నియమం అవసరం.

పూర్వపద ఢీకొనడం: వంతెనను పునఃసంఖ్య చేయండి

రూటింగ్ పట్టిక ఒక పూర్వపదాన్ని ఒకే చోటుకు పంపుతుంది. VPN 172.17.0.0/16 నెట్టుతుండగా Docker వంతెన ఇప్పటికే అక్కడ ఉంటే, తక్కువ మెట్రిక్ గెలుస్తుంది: Docker తన కనెక్ట్ అయిన మార్గాన్ని మెట్రిక్ 0 వద్ద ఇన్స్టాల్ చేస్తుంది, నెట్టబడిన మార్గం 50 వద్ద వస్తుంది. అప్పుడు Docker పని చేస్తూనే సొరంగం విరిగినట్లు కనిపిస్తుంది, లేదా దానికి విరుద్ధంగా, ఇన్స్టాలేషన్ క్రమాన్ని బట్టి. మెట్రిక్తో పోరాడే బదులు వంతెనను పునఃసంఖ్య చేయండి.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

మార్పు తర్వాత Dockerను పునఃప్రారంభించి పాత పూల్తో నిర్మించిన నెట్వర్క్లను మళ్లీ సృష్టించండి. బదులుగా మెట్రిక్ మార్చడం ఘర్షణను తదుపరి బూట్కు కదిలిస్తుంది.

VMలకు మళ్లీ మరో ప్రత్యుత్తరం కావాలి

డిఫాల్ట్ NAT నెట్వర్క్లోని libvirt అతిథి హోస్ట్ రూటింగ్ను వారసత్వంగా పొందుతుంది, హోస్ట్ సొరంగం డిఫాల్ట్ మార్గాన్ని కలిగి ఉన్న క్షణం బయటకు చేరుకోవడం ఆపేస్తుంది. అతిథిని వంతెన లేదా macvtap పరికరానికి మార్చడం భౌతిక నెట్వర్క్లో అతనికి సొంత మార్గాన్ని ఇస్తుంది. virt-managerలో హార్డ్వేర్ జోడించండి, Network ఎంచుకోండి, మూలాన్ని macvtap హోస్ట్ పరికరానికి సెట్ చేయండి, మోడల్గా virtio ఉంచండి, ఆపై పాత NAT ఇంటర్ఫేస్ను నిష్క్రియం చేయండి.

macvtap అతిథి సాధారణంగా తన సొంత హోస్ట్ను చేరుకోలేదు. అది లోపం కాదు, ఆశించిన ప్రవర్తన, మరియు అది మీరు వదిలివేసే గమనికలో ఉండాలి.

హోస్ట్ LAN మాత్రమే అవసరమైన అతిథికి, విక్రేత క్లయింట్లో తప్పిపోయిన స్విచ్ ఉండవచ్చు: Mullvad తో mullvad lan set allow libvirt తాకకుండా స్థానిక చేరికను పునరుద్ధరిస్తుంది. మరియు కంటైనర్ సొరంగం ద్వారా మాత్రమే చేరుకోగలిగేలా ఉండాలంటే, ప్రచురించిన పోర్టును సొరంగ చిరునామాకు కట్టండి, -p 10.8.0.5:8080:8080, ప్రతి చిరునామాలో ప్రచురించే బదులు.