Apache 2.4 తో Subversion హోస్ట్ను VPN వినియోగదారులకు పరిమితం చేయండి

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

ServerName నిజానికి ఏమి నిర్ణయిస్తుంది

పేరు ఆధారిత వర్చువల్ హోస్టింగ్ Host హెడర్ను ServerName మరియు ServerAlias నమోదులతో పోల్చి, ఒక హోస్ట్ను ఎంచుకుని దాన్ని అభ్యర్థనను నిర్వహించనిస్తుంది. కనెక్షన్ను ముందుగా సర్వర్కు చెందిన Listen సాకెట్ అంగీకరించింది, హోస్ట్ కాదు. అందుకే ప్రైవేట్లా కనిపించే పేరు ఎలాంటి రక్షణ ఇవ్వదు: సాకెట్ను చేరుకునే ఏ క్లయింట్ అయినా ఆ Host హెడర్ను పంపవచ్చు. పేరు ఒక రూటింగ్ కీ, రూటింగ్ కీలను పిలిచేవాడు ఎంచుకుంటాడు.

ఊహించకుండా మ్యాపింగ్ను చూడవచ్చు. apachectl -S ప్రతి హోస్ట్, దాని పోర్ట్ మరియు పేర్లను ముద్రిస్తుంది, చిరునామాకు ఏది డిఫాల్ట్ అని గుర్తిస్తుంది.

RequireAll రెండు తనిఖీలను తప్పనిసరి చేసే కంటైనర్

Apache 2.4 ఒక విభాగం యొక్క Require సూచనలను అంతర్లీన RequireAny లో చుట్టుతుంది, కాబట్టి రెండు నగ్న సూచనలు అంటే వాటిలో ఏదో ఒకటి సరిపోతుంది. కంటైనర్ను జోడించండి, అర్థం తిరగబడుతుంది:

<Location /svn/repo>
    AuthType Basic
    AuthName "Subversion"
    AuthBasicProvider file
    AuthUserFile /etc/apache2/svn.htpasswd
    <RequireAll>
        Require ip 10.8.0.0/24
        Require valid-user
    </RequireAll>
</Location>

RequireAll రెండు షరతులను కోరుతుంది: సొరంగ పరిధిలోని మూల చిరునామా మరియు రిపాజిటరీ అంగీకరించే వినియోగదారు. Subversion URL కు VPN-మాత్రమే అంటే ఇదే అర్థం ఉండాలి. mod_authz_core సూచన కంటైనర్ నియమాలను పత్రీకరిస్తుంది. బ్లాక్ను రిపాజిటరీ యొక్క ఇప్పటికే ఉన్న Location లో ఉంచండి, ఇప్పటికే పనిచేస్తున్న DAV సూచనలను వాటి స్థానంలో ఉంచండి, ఎందుకంటే ఈ భాగం AuthType, పాస్వర్డ్ ఫైల్ లేదా మార్గ-స్థాయి అనుమతిని ఏదీ మార్చదు.

మూల పరీక్ష mod_authz_host నుండి వస్తుంది, కాబట్టి మరేదైనా డీబగ్ చేయడానికి ముందు అది లోడ్ అయిందని నిర్ధారించండి: apachectl -M | grep authz_host.

Apache మూల్యాంకనం చేసే చిరునామా సాకెట్ చిరునామా

Require ip కనెక్షన్ కోసం Apache నమోదు చేసిన చిరునామాతో పోలుస్తుంది, అది క్లయింట్ తనకు ఉందని భావించే చిరునామా కాదు.

VPN తన చిరునామాలను అనువాదం లేకుండా రూట్ చేసినప్పుడు, Apache సొరంగ చిరునామాను చూస్తుంది, 10.8.0.0/24 సరిపోతుంది. గేట్వే అనువదించినప్పుడు, Apache గేట్వేను చూస్తుంది, నియమం నిశ్శబ్దంగా ఏదీ సరిపోలదు; హోస్ట్ ముందు TLS ముగించే లోడ్ బ్యాలెన్సర్ వెనుక కూడా అదే జరుగుతుంది. ఆ సందర్భానికి mod_remoteip ఉంది. బ్యాలెన్సర్ కోసం RemoteIPTrustedProxy తో పాటు RemoteIPHeader X-Forwarded-For నమోదైన చిరునామాను భర్తీ చేస్తుంది, అప్పుడే పరిధికి పోల్చడానికి ఏదో ఉంటుంది.

ఏదైనా ఫార్వార్డింగ్ హెడర్ను నమ్మడం ఏ నియమం లేకపోవడం కంటే అధ్వాన్నం. ఏ క్లయింట్ అయినా 10.8.0.9 ఉన్న X-Forwarded-For పంపి, విశ్వసనీయ హాప్కు ఎప్పుడూ లంగరు వేయని పరిధి తనిఖీని నెరవేర్చవచ్చు.

శ్రోత మరియు రిపాజిటరీ విధానాన్ని పొరలుగా చేయండి

బైండింగ్ ప్రత్యేక నియంత్రణ, తరచుగా సులభమైనది. Listen 10.8.0.1:443 ఏ సాకెట్లు ఉన్నాయో నిర్ణయిస్తుంది, ఎప్పుడూ తెరవని సాకెట్పై అభ్యర్థన హోస్ట్ను ఎంచుకోలేదు. ధర ప్రారంభ క్రమం: Apache ప్రారంభమయ్యేటప్పుడు సొరంగ ఇంటర్ఫేస్ డౌన్ ఉంటే, బైండింగ్ విఫలమవుతుంది, సేవ పైకి రాదు. దాన్ని యూనిట్ క్రమంతో జత చేయండి, లేదా సొరంగం నుండి స్వతంత్రంగా ఉన్న చిరునామాకు బైండ్ చేయండి.

మార్గ అనుమతులు AuthzSVNAccessFile లోనే ఉంటాయి. సైట్కు చెల్లుబాటు అయ్యే ఖాతా ప్రాజెక్ట్ మార్గానికి రాయడం యాక్సెస్తో సమాన అనుమతి కాదు, నెట్వర్క్ నియమం దాన్ని మార్చదు.

బ్లాక్ చేర్చిన ఫైల్లో ఉన్నప్పుడు విభాగ విలీనంపై శ్రద్ధ వహించండి. Apache నెస్టెడ్ విభాగాలలో అనుమతి కంటైనర్లను విలీనం చేస్తుంది, అత్యంత నిర్దిష్టంగా సరిపోలే విభాగం అవసరాన్ని జోడించకుండా భర్తీ చేయవచ్చు, కాబట్టి సన్నని విభాగం తనది నిర్వచించినప్పుడు /svn నియమం /svn/repo/trunk వరకు చేరకపోవచ్చు.

పూర్తయింది అని చెప్పే ముందు రెండు నిరాకరణలను నిరూపించండి

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

ప్రతి సందర్భానికి ఒక ఆదేశం సరిపోతుంది: curl -sI -u user:pass https://svn.example.com/svn/repo/, తర్వాత స్థితి పంక్తిని చదవండి. పనిచేసే సందర్భాన్ని నిజమైన క్లయింట్ ద్వారా కూడా పునరావృతం చేయండి, ఎందుకంటే svn info commit మరియు నవీకరణలు ఉపయోగించే DAV పద్ధతులను సాధన చేస్తుంది.

నాలుగింటిలో ఏదైనా ఫలితం మీరు ఉద్దేశించిన విధానంతో సరిపోలకపోతే, కాన్ఫిగరేషన్ పూర్తి కాలేదు, హోస్ట్ పేరు మార్చడం దాన్ని మార్చదు.