FreeBind vs After=: systemd సాకెట్‌ను VPN చిరునామాకు కట్టడం

బూట్ సమయంలో స్థిర VPN చిరునామాను కట్టే సాకెట్ యూనిట్, టన్నెల్ దానిని కేటాయించకముందే విఫలమవచ్చు, దాని వెనుక ఉన్న సేవ ఎప్పటికీ ప్రారంభం కాదు. రెండు స్విచ్‌లు పరిష్కారాల్లా కనిపిస్తాయి, ఆ సమస్యలోని వేర్వేరు సగాలను పరిష్కరిస్తాయి. చిరునామా ఇంకా లేనప్పుడే FreeBind systemd-ను శ్రోతను సృష్టించనిస్తుంది. After= పనులను మాత్రమే క్రమబద్ధీకరిస్తుంది, కాబట్టి విషయాలు ఎప్పుడు ప్రారంభమవుతాయో మారుస్తుంది, కానీ చిరునామా ముందుగా రావడం జరగదు.

రెండు వేర్వేరు సమస్యలు, రెండు వేర్వేరు స్విచ్‌లు

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

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

FreeBind: చిరునామా కంటే ముందే శ్రోత

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

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

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

systemd సాకెట్ సూచన ఈ ఎంపిక వెనుక ఉన్న IPv4, IPv6 ప్రవర్తనను నమోదు చేస్తుంది, ముఖ్యమైన వివరం ఏమిటంటే అది కట్టడానికి వర్తిస్తుంది, రూటింగ్‌కు కాదు. అందులో ఏదీ చిరునామాను కేటాయించదు, VPN ప్రారంభించదు. FreeBind శ్రోతకు ఇచ్చిన అనుమతి, ఇంటర్‌ఫేస్‌కు ప్రత్యామ్నాయం కాదు.

After=, Wants=: క్రమం సంసిద్ధత కాదు

క్రమం, అవసరం వేర్వేరు అక్షాలు, వాటిని కలపడం సరైన క్రమంలో ప్రారంభమైనా విఫలమయ్యే యూనిట్‌లను సృష్టిస్తుంది. After=vpn-client.service అంటే రెండు పనులు ప్రారంభమైతే, ఇది మరొకటి ప్రారంభమయ్యే వరకు వేచి ఉంటుంది అని మాత్రమే. ఇది VPN-ను లాగదు, VPN కనెక్ట్ కావడం పూర్తయ్యే వరకు వేచి ఉండదు.

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

systemctl cat, systemctl show -p After -p Wants -p Requires ఉపయోగించి యూనిట్ నిజంగా ఏమి ప్రకటిస్తుందో తనిఖీ చేయండి. మూడు వేర్వేరు డైరెక్టరీల drop-in మీరు ఎప్పుడూ రాయని సూచనలను జోడించవచ్చు, systemd ప్రభావవంతమైన యూనిట్‌ను మాత్రమే చదువుతుంది.

network-online.target చేయనిది

network-online.target తర్వాత క్రమబద్ధీకరించిన యూనిట్, నెట్‌వర్క్ మేనేజర్ నెట్‌వర్క్‌ను ఉపయోగించదగినదిగా ప్రకటించే వరకు వేచి ఉంటుంది, ఇది బూట్ సమకాలీకరణ బిందువు, నిరంతర షరతు కాదు. నిర్దిష్ట టన్నెల్ పైన ఉందా అని చెప్పదు, మధ్యాహ్నం తర్వాత VPN మళ్లీ కనెక్ట్ అయినప్పుడు మళ్లీ మండదు. దానిని పునఃకనెక్షన్ మానిటర్‌గా భావించడం ఆ లక్ష్యం యొక్క అత్యంత సాధారణ తప్పు పఠనం.

systemd ప్రాజెక్ట్ ఆ భేదాన్ని నేరుగా నమోదు చేస్తుంది, ఆచరణాత్మక పరిణామం ఏమిటంటే టన్నెల్ చిరునామా అవసరమైన ప్రతిదీ ఆధారతను తనే కలిగి ఉండాలి. network-online కోసం వేచి తర్వాత టన్నెల్ చిరునామాను కట్టే యూనిట్, టన్నెల్ యాదృచ్ఛికంగా ముందుగా పైకి వచ్చినప్పుడు మాత్రమే సరైనది, అది యాదృచ్ఛికం, రూపకల్పన కాదు.

మీరు నిజంగా ఎంచుకున్న జీవిత చక్రాన్ని పరీక్షించండి

స్వచ్ఛమైన బూట్, చిరునామా కనిపించిన తర్వాత వచ్చిన అభ్యర్థన, VPN పడిపోయి తిరిగి వచ్చిన తర్వాత ప్రవర్తన పరీక్షించండి. ఆ మూడు సందర్భాలు పనిచేసే శ్రోతను పనిచేసే సేవ నుండి వేరు చేస్తాయి.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

మొదటి ఆదేశం రీస్టార్ట్‌కు ముందే యూనిట్ ఫైల్ లోపాలను పట్టుకుంటుంది, రెండవది విలీనమైన యూనిట్‌ను చూపుతుంది, మూడవది శ్రోత ఉందా ఏ చిరునామాపై ఉందా అని నిరూపిస్తుంది. టన్నెల్ చిరునామా ఆశించిన చోట wildcard చిరునామాపై శ్రోత ఉండడం అనేది ఖాళీ ListenStream తొలగించాల్సిన అదే మిగిలిన భాగం. చిరునామా కదిలిందా చూడటానికి VPN పునఃకనెక్షన్ తర్వాత మూడవ ఆదేశాన్ని మళ్లీ నడపండి.

జీవిత చక్రాన్ని ఉద్దేశపూర్వకంగా ఎంచుకోండి: స్థిరమైన చిరునామా తిరిగి రావడానికి వేచి ఉండే స్వేచ్ఛగా కట్టిన శ్రోత, లేదా టన్నెల్‌తో ఆగి పునరుద్ధరణలో మళ్లీ ప్రారంభమయ్యే సేవ. ఇవి వేర్వేరు రూపకల్పనలు, వేర్వేరు విధాలుగా విఫలమవుతాయి. తర్వాత ప్రవేశ విధానాన్ని మీరు ఉద్దేశించిన మూలాలు, మార్గాలకు కట్టి ఉంచండి, ఎందుకంటే గమ్య చిరునామాను కట్టడం వల్ల ఆమోదించిన ప్యాకెట్లు విశ్వసనీయ ఇంటర్‌ఫేస్ ద్వారా వచ్చి ఉండాలని కోరదు.