Bi zerbitzu-helbide OpenVPN bezero bakarrean: iroute eta lo

Aplikazioak bere tunel-helbidean erantzuten du, eta horretarako dokumentatu duzun helbidea ez doa inora. Ezerk ez du kexarik egiten OpenVPN erregistroan, parekideak konektatuta agertzen dira, eta hubak bezero bat baino ez du zerrendatzen. Hutsegitea da bezero bateko bigarren helbidea bi gertaera bereizi direla: ostalariak hura eduki behar du, eta hubak jakin behar du zein parekidetan duen jabetza. Bat bestea gabe konponduz gero, trafikoak huban hiltzen du edo etxera biderik gabe iristen da.

Aliasa lokala da, jabetza urrutikoa

Tunel-helbidea negoziatu egiten da, beraz bi muturrek eskua ematean ikasten dute. Zerbitzu-helbide gehigarria ez da batere negoziatzen, eta horregatik hura gehitzeak berak ez du ezer aldatzen huban. Bezeroak berehala eduki dezake helbidea, eta zerbitzariak trafiko hori bere bide lehenetsira bidaliko du edo baztertu egingo du. Bi erregistro sortu behar dira, bi toki desberdinetan.

Bezeroan helbidea ostalariarena da, eta loopback da inoiz esteka fisikotan agertu behar ez duen zerbitzu-identitatearentzako etxe naturala. Huban parekideen eta aurrizkiaren arteko mapaketa deklarazio bereizia da, zerbitzariak soilik irakurtzen duena. Bi erregistroetako batek ere ez du bestea inplikatzen.

Mantendu bi barrutiak bereizita zure oharretan ere. Adibide bateko helbideak dokumentaziorako balioak dira, eta LAN erreal batekin gainjartzea konfigurazio funtzional bat hautsi gisa ikusteko modurik azkarrena da.

Gehitu helbidea bezeroan modu iraunkorrean

Jarri zerbitzu-helbidea loopbacken ostalari-aurrizki batekin, ostalariak sarrera lokal gisa trata dezan eta ez iristeko azpisare gisa. ip address add 10.66.0.10/32 dev lo hori egiten du helbide baterako, eta komandoa bigarren helbide baterako errepikatzeak bi zerbitzu modelatzen ditu.

Exekutatu behin-behineko proba gisa, eta gero eraman ostalariaren sare-konfigurazioa duen tokira, zeren exekuzio-denborako gehigarria berrabiaraztean desagertzen da eta bikoiztuak pilatzen dira berriro konektatzerakoan. Sarearen ondoren ordenatutako systemd unitate bat aukera bat da, eta banaketaren sare-kudeatzailea beste bat. Aukeratzen duzuna aukeratu, helbideak existitu behar du aplikazioa lotu aurretik, edo zerbitzua socket okerrean agertzen da. Egiaztatu ip address show dev lo erabiliz berrabiarazi ondoren, eta ez eskuzko komandoaren ondoren.

Lotzea helbideratzetik bereizitako erabakia da. Helbide guztietan entzuten duen aplikazio batek inoiz asmo ez zenituen interfazeetan onartzen du trafikoa, beraz zuzendu zerbitzu-helbide zehatzera. Orduan sarrerako politika lokalak zerbait zehatza du bat etortzeko.

Eskatu hubak benetan irakurtzen duen CCD fitxategian

Zerbitzarian, jabetza-deklarazioa autentifikatutako izen komunak aukeratutako bezero bakoitzeko fitxategira doa, client-config-dir-ek izendatutako direktorioaren barruan. Lerroa iroute 10.66.0.10 255.255.255.255 da, helbide bakoitzeko bat, eta zerbitzariari esaten dio zein parekidek jaso behar duen helmuga horretarako trafikoa.

Bi xehetasunek isilka apurtzen dute hau. Fitxategi-izenak zerbitzariak benetan erabiltzen duen izenarekin bat etorri behar du, eta hori desberdina da username-as-common-name jokoan dagoenean. Eta iroute TUN moduan soilik da eraginkorra bezero-konfigurazio direktorioa konfiguratuta dagoenean, beraz lerro berak ez du ezer egiten zubitutako inplementazio batean. Gehitu lerroak lehendik dagoen fitxategiari ordezkatu beharrean, agian jada helbide finko bat edo push aukerak daramatzalako. OpenVPN 2.6 erreferentziak direktorioa zein jabetza-direktiba dokumentatzen ditu.

Hubaren nukleoak ere bide bat behar du helmuga horietara, tokian sortutako trafikoak tunel-prozesuan sartzeko. Zerbitzariaren konfigurazioan route 10.66.0.10 255.255.255.255-ek zerbitzariak berak sortzen duen trafikoa estaltzen du, beste bezero batzuek push "route 10.66.0.10 255.255.255.255" behar duten bitartean helmuga beraiek ikasteko.

Bideratzea eta autorizazioa bereizita jarraitzen dute. Bultzatutako bide batek bezeroari esaten dio nora bidali paketeak eta ez du ezer ematen; zerbitzuak deitzailea bere baldintzetan onartu behar du oraindik.

Egiaztatu sarrerako politika eta erantzun-bidea

Aliaserari zuzendutako pakete bat jabe den ostalarira iristen da sarrera lokal gisa, beraz galdera da firewall lokalak iturri eta portu hori onartzen duen. Onartu zerbitzu-portu zehatza VPN iturri-barrutitik, helbide osoa ireki beharrean.

Erantzunek deitzailera itzultzeko bidea behar dute. Tunel-pool normalaren barruko deitzailearentzat bide hori badago, tunel-gailuak daramalako. Beste sare bideratu baten atzean dagoen deitzaileak sare horren itzulera-bidea ere behar du, eta hemen galtzen dituzte paketeak konfigurazio asimetrikoek.

Adi egon portu berean beste helbide batera lotuta dagoen bigarren entzule batekin, nukleoak bat datorren socketari ematen baitio eta emaitzak ausazkoak dirudite. Egiaztatu ss -lntp erabiliz eta berretsi lotutako helbidea zerbitzu-aliasa dela. Iturburu-NAT ez da hemen beharrezkoa, eta hura gehitzeak zure erregistroek behar duten deitzailearen identitatea ezkutatzen du.

Probatu helbideak eta jabetza bereizita

Probatu bi urratsetan. Lehenengo berretsi jabe den ostalariak zerbitzura bere aliasetik berarengandik irits daitekeela, eta horrek lotze- eta firewall-arazoak bideratzetik bereizten ditu. Gero probatu benetako VPN deitzaile batetik aplikazioaren autentifikazioa erabiliz. Lehenengoa pasatzen denean eta bigarrena huts egiten duenean, falta den pieza hubaren aldean dago.

Egiaztatu konexio batetik bizirik dirauten hutsegite-moduak ere: aliasak esleituta jarraitzen du tunela behean dagoenean, eta hubak bere bidea gordetzen du parekidea falta denean. Inongo objektuk bere bakarrik ez du frogatzen zerbitzua irisgarria denik, eta horregatik bi urratseko probak gainditzen du eramangarri batetik egindako ping bakar bat.