VM లో VPN ద్వారా హోస్ట్ ట్రాఫిక్ను రూట్ చేయడం: ఆరు తనిఖీలు
VM ను దాని స్వంత హోస్ట్ ట్రాఫిక్ను రూట్ చేసే VPN గేట్వేగా మార్చడానికి ఆరు క్రమ తనిఖీలు: అడాప్టర్ మోడ్, ఫార్వార్డింగ్, NAT, హోస్ట్ రూట్లు, DNS, MTU.
క్రమంగా చేసే ఆరు తనిఖీలు, VM తన స్వంత హోస్ట్కు VPN గేట్వే కాగలదా అని నిర్ణయిస్తాయి. హైపర్వైజర్ ఇవేవీ మీ కోసం చేయదు: టన్నెల్ అతిథి సొంతం, రూట్ హోస్ట్ సొంతం, వాటి మధ్య నెట్వర్క్ సాధారణ రూటింగ్. ఈ జాబితాను ఉంచుకోవడానికి కారణం, ఒక అడుగు దాటవేస్తే ఎప్పుడూ అదే లక్షణం వస్తుంది, నిశ్శబ్దం, హోస్ట్ అతిథిని సంతోషంగా పింగ్ చేస్తుంది కానీ లోపల ఏదీ చేరుకోదు.
కారణంతో ప్రారంభించండి. ఒకటి లేదా కార్పొరేట్ క్లయింట్ అతిథి లోపల మాత్రమే ఇన్స్టాల్ అవుతుంది, లేదా విధానం దానిని అక్కడే ఉంచుతుంది, మరియు మీకు ఇంకా హోస్ట్ నుండి లోపలి build సర్వర్ కావాలి. హోస్ట్కు దాని స్వంత క్లయింట్ అనుమతి ఉంటే అదే చేయండి: హోస్ట్లో ఒక టన్నెల్ ఎప్పుడూ రెండు నెట్వర్క్లు మరియు ఒక NAT కంటే మెరుగురు.
తనిఖీ 1: హోస్ట్కు చిరునామా ఇవ్వగల లింక్ కావాలి
హోస్ట్కు అతిథి యొక్క రెండవ అడాప్టర్ ఉన్న అదే ప్రిఫిక్స్లో ఇంటర్ఫేస్ ఉండాలి. VirtualBox లో host-only, VMware Workstation లో host-only లేదా అనుకూల VMnet, QEMU/KVM లో అంతర్గత బ్రిడ్జ్ లేదా tap పరికరం, మరియు Hyper-V లో Internal స్విచ్ అన్నీ అర్హత కలిగినవి. అతిథి 192.168.56.2, హోస్ట్ 192.168.56.1, ప్రిఫిక్స్ 192.168.56.0/24 నేను ల్యాబ్లలో ఉపయోగించే అమరిక.
QEMU యొక్క వినియోగదారు-మోడ్ నెట్వర్కింగ్ (-netdev user, డిఫాల్ట్ SLIRP బ్యాకెండ్) మరియు VirtualBox NAT ఈ తనిఖీలో పూర్తిగా విఫలమవుతాయి. అతిథి ప్యాకెట్లు హోస్ట్పై ప్రాక్సీ ప్రక్రియకు చేరుతాయి, కాబట్టి హోస్ట్ అతిథి చిరునామాలను మోసే పరికరాన్ని ఎప్పుడూ చూడదు మరియు రూట్ను చూపడానికి ఏమీ ఉండదు. Hyper-V యొక్క Default Switch కూడా అదే కథ. హోస్ట్ నుండి ping 192.168.56.2 విఫలమైతే ఆపండి: తర్వాత జోడించే ఏ రూట్ దానిని సరిచేయదు.
తనిఖీ 2: అతిథి ఫార్వార్డ్ చేస్తుంది మరియు అనువదిస్తుంది
హోస్ట్ నుండి వచ్చే ప్యాకెట్లు host-only మూల చిరునామా మరియు అంతర్గత గమ్యంతో వస్తాయి, కాబట్టి అతిథి వాటిని ఫార్వార్డ్ చేసి తర్వాత తన టన్నెల్ చిరునామా వెనుక దాచాలి. Linux అతిథిలో ఇది ఫార్వార్డింగ్, ఒక FORWARD accept జత, మరియు టన్నెల్ వైపు source NAT అని అర్థం:
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE
MASQUERADE నియమం మనుషులు వదిలే భాగం. కార్పొరేట్ రౌటర్లు 192.168.56.0/24 ఉన్నట్లు అరుదుగా తెలుసుకుంటాయి; నియమంతో అంతర్గత సర్వర్లు అతిథి టన్నెల్ చిరునామాను చూసి దానికి సమాధానం ఇస్తాయి, మరియు సమాధానం అతిథి వైపు తిరిగి దారి కనుగొంటుంది.
Windows అతిథి మరింత అసౌకర్యంగా ఉంటుంది. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters కింద IPEnableRouter=1 అనువాదం లేకుండా ఫార్వార్డింగ్ను ఆన్ చేస్తుంది, కాబట్టి కార్పొరేట్ రూటింగ్ ఇప్పటికే మీ host-only ప్రిఫిక్స్ వైపు తిరిగి చూపే చోట మాత్రమే ఇది పనిచేస్తుంది. Internet Connection Sharing అనువదిస్తుంది, కానీ పంచుకున్న అడాప్టర్ను 192.168.137.1 కు తిరిగి సంఖ్యాీకరిస్తుంది, కాబట్టి హోస్ట్ రూట్లు రాయడానికి ముందు అది నిజంగా తీసుకున్న చిరునామాను చదవండి.
తనిఖీ 3: హోస్ట్ రూట్లు అతిథి పేరు చెబుతాయి, టన్నెల్ కాదు
హోస్ట్కు అవసరమైన ప్రిఫిక్స్లు మాత్రమే అతిథి ద్వారా పంపండి. Linux లో ప్రతి ప్రిఫిక్స్కు ఒక రూట్ సరిపోతుంది మరియు అది శుభ్రంగా తిరిగి మారుతుంది:
sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40
Windows లో సమానమైనది route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. పరీక్షిస్తున్నప్పుడు -p వదిలేయండి, చెడు రూట్ రీబూట్లో చనిపోతుంది, మరియు మార్గం పనిచేసిన తర్వాత దాన్ని జోడించండి. హోస్ట్ డిఫాల్ట్ రూట్ను తీసివేయవద్దు, హోస్ట్లోని ప్రతి అప్లికేషన్ టన్నెల్ ఉపయోగించాల్సి ఉంటే తప్ప; నిజంగా పూర్తి టన్నెల్ అవసరమైతే, రెండు /1 రూట్లను జోడించి హైపర్వైజర్ నెట్వర్క్కు నేరుగా రూట్ను ఉంచండి:
sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2
Windows హోస్ట్లో ఇంటర్ఫేస్ మెట్రిక్ను కూడా తనిఖీ చేయండి. host-only అడాప్టర్ నిష్క్రియంగా ఉన్నప్పుడు జోడించిన రూట్ పట్టికలో ఉంటుంది కానీ ఎప్పుడూ ట్రాఫిక్ మోసుకెళ్లదు, మరియు తక్కువ మెట్రిక్ ఉన్న రెండవ అడాప్టర్ అదే ప్రిఫిక్స్ కోసం వెతుకుడును గెలవవచ్చు.
తనిఖీ 4: DNS రూట్ను అనుసరిస్తుంది, టన్నెల్ డిఫాల్ట్ను కాదు
రూట్లు ప్యాకెట్లను కదిలిస్తాయి; ఏ పేర్లు ప్యాకెట్లను సృష్టిస్తాయో రిజాల్వర్ నిర్ణయిస్తుంది. హోస్ట్ రిజాల్వర్ను భర్తీ చేయడం బదులు కార్పొరేట్ రిజాల్వర్ను కార్పొరేట్ జోన్కు పరిమితం చేయండి, మరియు కొత్త రూట్ ఇప్పటికే చేరే DNS సర్వర్ వైపు దాన్ని చూపండి. హోస్ట్లో systemd-resolved ఉంటే:
resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'
Windows లో పేరు రిజల్యూషన్ విధాన పట్టికలోని ఎంట్రీ అదే పని చేస్తుంది: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. అతిథి host-only చిరునామలో తన స్వంత రిజాల్వర్ను నడుపుతుంటే, దాని బదులు ఆ చిరునామాను ఉపయోగించండి, కానీ అది loopback లో కాదు, 192.168.56.2 లో సమాధానం ఇస్తుందని నిర్ధారించిన తర్వాత మాత్రమే.
తర్వాత నెమ్మదిగా లోడయ్యే పేజీలకు DNS ను నిందించే ముందు MTU ను తనిఖీ చేయండి. టన్నెల్ ఇంటర్ఫేస్ హోస్ట్ యొక్క 1500 బైట్ ఇంటర్ఫేస్ కంటే చిన్నది, కాబట్టి DF బిట్ పెట్టి పూర్తి పరిమాణ సెగ్మెంట్లను పంపే హోస్ట్ వాటిని అతిథి లోపల ఎక్కడో కోల్పోతుంది. సాంప్రదాయ లక్షణం పనిచేసే ping మరియు TLS చేతులు కలపడం తర్వాత ఆగిపోయే అంతర్గత వెబ్ యాప్. అతిథి ఫార్వార్డ్ మార్గంలో MSS ను బిగించండి:
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
తనిఖీ 5: రెండు చివరల నుండి ధృవీకరించండి
హోస్ట్ నుండి అంతర్గత చిరునామాకు traceroute లేదా tracert మొదటి హాప్గా భౌతిక గేట్వేను కాదు, 192.168.56.2 చూపాలి. అతిథిలో అదే ప్రయత్నం బయటకు వెళ్లడాన్ని గమనించండి: tcpdump -ni any host 10.20.30.40 host-only వైపు ఫార్వార్డ్ అయిన అభ్యర్థనను మరియు టన్నెల్లో అనువదించిన దాన్ని చూపుతుంది. బయటకు వెళ్లి, తిరిగి వచ్చి కూడా హోస్ట్ను నిశ్శబ్దంగా వదిలే అభ్యర్థన తిరుగు మార్గాన్ని సూచిస్తుంది.
దీనిలో ఎక్కువ భాగాన్ని రెండు వైఫల్యాలు వివరిస్తాయి. ఒకటి NAT నియమం లేకపోవడం వల్ల అతిథి టన్నెల్ host-only ప్రిఫిక్స్ కోసం తిరుగు రూట్ మోసుకెళ్లదు, లేదా రీబూట్ తర్వాత అతిథి వద్ద లేని చిరునామా వైపు హోస్ట్ రూట్ చూపుతుంది. గత సెషన్ నోట్లను నమ్మడం బదులు ip -br addr మరియు ip route get తో చిరునామాలను మళ్లీ చదవండి.
తనిఖీ 6: రీబూట్ మరియు హైపర్వైజర్ అప్గ్రేడ్ను తట్టుకునేలా చేయండి
రెండు సగాలను శాశ్వతం చేయండి: హోస్ట్లో netplan లేదా NetworkManager రూట్ కాన్ఫిగరేషన్, Windows లో route add ... -p, మరియు /etc/sysctl.d/ లో net.ipv4.ip_forward=1 తో పాటు అతిథిలో మళ్లీ లోడయ్యే ఫైర్వాల్ నియమాల సమితి. కాన్ఫిగరేషన్ ధృవీకరించబడిన వెంటనే, తదుపరి కార్పొరేట్ క్లయింట్ అప్డేట్ రాకముందు అతిథి snapshot తీసుకోండి.
హైపర్వైజర్ తన అడాప్టర్లను మళ్లీ సృష్టించినప్పుడు host-only నెట్వర్క్లు తిరిగి సంఖ్యాీకరించబడతాయి, ఇది 192.168.56.0/24 పై నిర్మించిన ప్రతి రూట్ మరియు NAT నియమాన్ని నిశ్శబ్దంగా చెల్లనిదిగా చేస్తుంది. అప్గ్రేడ్ తర్వాత మొదటి మూడు తనిఖీలను క్రమంగా మళ్లీ నడపండి; ఇది ఒక నిమిషం తీసుకుంటుంది మరియు హోస్ట్కు దాని రూట్ ఇంకా ఉండగా అతిథి కొత్త సబ్నెట్కు మారిన సందర్భాన్ని పట్టుకుంటుంది.
IPv6 కు దాని స్వంత పర్యాయం కావాలి. ip6tables నియమాలు, AAAA రికార్డులు మరియు హోస్ట్ రూట్ల రెండవ కుటుంబం IPv4 సెటప్ను అనుసరించవు, మరియు IPv6 ద్వారా చేరగల కార్పొరేట్ సేవ IPv4 పనిచేస్తున్నప్పుడు శాశ్వతంగా పాడైనట్లు కనిపిస్తుంది.
ఉత్తీర్ణమైనా కాకపోయినా, క్రమంగా: హోస్ట్ అతిథి host-only చిరునామాను పింగ్ చేయగలదు; అతిథి టన్నెల్ వైపు ఫార్వార్డ్ మరియు MASQUERADE చేస్తుంది; ip route get అంతర్గత ప్రిఫిక్స్ కోసం గేట్వేగా అతిథిని తిరిగి ఇస్తుంది; కార్పొరేట్ పేర్లు పరిమిత రిజాల్వర్ ద్వారా పరిష్కరించబడతాయి; traceroute అతిథిని మొదట చూపుతుంది; మరియు అదే ఆరు సమాధానాలు రీబూట్ను తట్టుకుంటాయి.