To tenesteadresser på éin OpenVPN-klient: iroute og lo

Programmet svarar på sin tunneladresse, og adressa du dokumenterte for det, fører ingen stad. Ingenting i OpenVPN-loggen klagar, peer-en viser seg som tilkopla, og huben listar nøyaktig éin klient. Holet er at ei ekstra adresse på ein klient er to skilde faktum: verten må eige ho, og huben må vite kva peer som eig ho. Handter den eine utan den andre, og trafikken døyr anten ved huben eller kjem fram utan ei rute heim.

Aliaset er lokalt, eigarskapet er eksternt

Ei tunneladresse vert forhandla, så begge endar lærer ho under handtrykket. Ei ekstra tenesteadresse vert ikkje forhandla i det heile, og difor endrar det ingenting på huben å leggje ho til i seg sjølv. Klienten kan eige adressa med ein gong, og tenaren sender framleis trafikken på standardvegen sin eller slepp han. Det må opprettast to postar på to ulike stader.

På klienten høyrer adressa til verten, og loopback er det naturlege heimen for ein tenesteidentitet som aldri bør visast på ei fysisk lenkje. På huben er peer-til-prefiks-kartlegginga ei eiga fråsegn som berre tenaren les. Ingen av postane føreset den andre.

Hald dei to områda skilde i notata dine òg. Adresser i eit døme er dokumentasjonsverdiar, og å overlappe dei med eit ekte LAN er den raskaste måten å få eit fungerande oppsett til å sjå øydelagt ut.

Legg til adressa på klienten varig

Legg tenesteadressa på loopback med eit vertsprefiks, slik at verten handsamar ho som lokal inngang og ikkje som eit subnett som skal nåast. ip address add 10.66.0.10/32 dev lo gjer det for éi adresse, og å gjenta kommandoen for ei andre adresse modellerer to tenester.

Køyr det som ein eingongstest, og flytt det deretter inn i det som eig nettverkskonfigurasjonen til verten, fordi eit tillegg under køyring forsvinn ved omstart, og duplikat hopar seg opp mellom gjenoppkoplingar. Ei systemd-eining ordna etter nettverket er eitt alternativ, og ein distribusjonsnettverkshandsamar er eit anna. Uansett kva du vel, må adressa finnast før programmet bind seg, elles startar tenesta på feil socket. Stadfest med ip address show dev lo etter ein omstart og ikkje etter den manuelle kommandoen.

Binding er ei avgjerd skild frå adressering. Eit program som lyttar på kvar adresse, godtek trafikk på grensesnitt du aldri meinte, så peik det mot den spesifikke tenesteadressa. Då har den lokale inngangspolicyen noko presist å matche.

Krev ho i CCD-fila som huben faktisk les

På tenaren går eigarskapserklæringa i fila per klient som vert vald av det autentiserte fellesnamnet, inne i katalogen som er namngjeven av client-config-dir. Linja er iroute 10.66.0.10 255.255.255.255, éi per adresse, og ho fortel tenaren kva peer som skal ta imot trafikk for den destinasjonen.

To detaljar bryt dette stille. Filnamnet må samsvare med namnet tenaren faktisk brukar, som er annleis når username-as-common-name er med i spelet. Og iroute verkar berre i TUN-modus med ein konfigurert klientkonfigurasjonskatalog, så same linja gjer ingenting i ei brua utrulling. Legg til linjer i den eksisterande fila i staden for å byte ho ut, sidan ho kan alt bera ei fast adresse eller push-alternativ. OpenVPN 2.6-referansen dokumenterer både katalogen og eigarskapsdirektivet.

Hubens eigen kjerne treng òg ein veg til desse destinasjonane, slik at lokalt generert trafikk kjem inn i tunnelprosessen. route 10.66.0.10 255.255.255.255 i tenarkonfigurasjonen dekkjer trafikk tenaren sjølv skapar, medan andre klientar treng push "route 10.66.0.10 255.255.255.255" for å lære destinasjonen sjølv.

Ruting og autorisasjon held seg skilde. Ei pusja rute fortel ein klient kvar pakkar skal sendast, og gjev ingenting; tenesta må framleis godta den kallande parten på sine eigne vilkår.

Kontroller inngangspolicy og returvegen

Ein pakke adressert til aliaset kjem til den eigande verten som lokal inngang, så spørsmålet er om den lokale brannmuren tillèt den kjelda og porten. Tillat den spesifikke tenesteporten frå VPN-kjeldeområdet i staden for å opne heile adressa.

Svar treng ei rute tilbake til den kallande parten. For ein kallande part i den vanlege tunnelpoolen finst den vegen alt, fordi tunnelinnretninga ber han. Ein kallande part bak eit anna ruta nettverk treng òg returruta til det nettverket, og det er her asymmetriske oppsett mistar pakkar.

Sjå opp for ein andre lyttar på same port bunden til ei anna adresse, fordi kjernen leverer til den socketen som passar, og resultata ser tilfeldige ut. Kontroller med ss -lntp og stadfest at den bundne adressa er tenesteyaliaset. Kjelde-NAT er ikkje naudsynt her, og å leggje det til skjuler identiteten til den kallande parten som loggane dine er avhengige av.

Test adresser og eigarskap kvar for seg

Test i to trinn. Stadfest først at den eigande verten kan nå tenesta på aliaset sitt frå seg sjølv, noko som skil bindings- og brannmurproblem frå ruting. Test deretter frå ein ekte VPN-kallande part med autentiseringa til programmet sjølv. Når det første går gjennom og det andre feilar, er den manglande biten på hub-sida.

Kontroller òg feilmodusane som overlever ei tilkopling: aliaset vert verande tildelt når tunnelen er nede, og huben held på ruta si når peer-en er borte. Ingen av objekta beviser åleine at tenesta er tilgjengeleg, og difor slår totrinnstesten ein einaste ping frå ein berbar PC.