ఒక ల్యాబ్ సర్వర్, మూడు విశ్వాస పాత్రలు, ఒక వైఫల్య డొమైన్

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

ఇప్పుడు అన్నింటినీ పంచుకునే మూడు పాత్రలు

VPN ప్రవేశం, ప్రైవేట్ సేవల సమూహం మరియు బిల్డ్ రన్నర్ వేర్వేరు విషయాలు కోరుతాయి. మొదటిదానికి పబ్లిక్ పోర్ట్ మరియు ప్రైవేట్ వైపు ఇరుకైన నెట్వర్క్ కావాలి. రెండవదానికి శాశ్వత నిల్వ మరియు అప్లికేషన్ రహస్యాలు కావాలి. మూడవది మరొకరు రాసిన కోడ్ను నిర్వహిస్తుంది.

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

క్రింది స్కెచ్ ఆ విభజనకు ప్రారంభ స్థానం, అధిక లభ్యతకు హామీ కాదు. దాన్ని ధృవీకరించాల్సిన పరికల్పనగా తీసుకోండి, పూర్తయిన రూపకల్పనగా కాదు.

మూడు పాత్రలను విభజించండి, మూడు ప్రక్రియలను కాదు

ఒక హోస్ట్పై మూడు అతిథులు మూడు అధికార సమూహాలను మరియు మూడు నెట్వర్క్ స్థానాలను ఇస్తాయి. అవి మూడు వైఫల్య డొమైన్లను ఇవ్వవు, రూపకల్పన అది బిగ్గరగా చెప్పాలి.

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

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

టోపాలజీని రాయండి, ఆపై దాన్ని సొంతం చేసుకున్న సాధనాలతో ధృవీకరించండి. తప్పు బ్రిడ్జ్పై కనిపించే అతిథి ఒక ఆవిష్కరణ, వివరం కాదు. ఏ సేవా కాన్ఫిగరేషన్ను మార్చే ముందు నెట్వర్క్ను సరిచేయండి.

VPN అతిథి తనకు చెందిన తలుపులను మాత్రమే తెరవనివ్వండి

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

ప్రైవేట్ వైపు నెట్వర్క్ రిమోట్ వినియోగదారులకు అవసరమైన సేవలను చేరుకుని అక్కడే ఆగాలి. అప్లికేషన్ ప్రామాణీకరణ ఆన్లోనే ఉంటుంది, ఎందుకంటే టన్నెల్ రవాణా, లాగిన్ కాదు. VPN అతిథి రూటింగ్ పట్టికను ఒక వాక్యంలో వివరించగలిగేంత చిన్నగా ఉంచండి. అంత సులభంగా వివరించలేకపోతే, సరిహద్దు ఇప్పటికే మసకబారింది.

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

హోస్ట్పై వినిపించే, నిర్వహణకు అవసరం లేని ఏదీ వినిపించకూడదు. ఇందులో హైపర్వైజర్ API ఉంది, దాన్ని పబ్లిక్ ఇంటర్ఫేస్పై బహిర్గతంగా వదిలేయడం సులభం.

బిల్డ్ ఉద్యోగాలకు వేరే రకమైన సరిహద్దు కావాలి

CI పని రిపోజిటరీ నియంత్రించే ఆదేశాలను నిర్వహిస్తుంది, కాబట్టి దాని విశ్వాసం ఎవరు కోడ్ను పుష్ చేయగలరనే దానిపై ఆధారపడి ఉంటుంది. షెల్ ఎగ్జిక్యూటర్ ఆ ఆదేశాలను హోస్ట్పై రన్నర్ వినియోగదారుగా నిర్వహిస్తుంది, అదే అందుబాటులో ఉన్న విస్తృత సరిహద్దు.

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

సేవా అతిథి డేటాను కలిగి ఉంటుంది, కాబట్టి దాని బ్యాకప్ ప్రణాళికే పనిచేయాలి. రిపోజిటరీలు, అప్లోడ్లు మరియు డేటాబేస్ను ఒకే షెడ్యూల్లో ఉంచండి. పని స్థితిని చదవడం బదులు పునరుద్ధరణను పరీక్షించండి.

మూడూ పంచుకునే వైఫల్యం కోసం ప్రణాళిక వేయండి

ఒక హోస్ట్ ఒక వైఫల్య డొమైన్. పునఃప్రారంభం టన్నెల్ను మరియు ప్రతి ప్రైవేట్ సేవను ఒకే క్షణంలో తొలగిస్తుంది, లోపలికి వెళ్లే మార్గం అత్యంత ముఖ్యమైనది అప్పుడే.

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

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

ప్రక్రియల ప్రారంభ క్రమం మార్గాలు మరియు DNS గురించి ఏమీ నిరూపించదు, కాబట్టి యూనిట్ స్థితులకు బదులు మార్గాన్ని పరీక్షించండి. రిమోట్ వినియోగదారుకు నిజంగా కావాల్సింది మార్గమే.