To tjenesteadresser på én OpenVPN-klient: iroute og lo

Programmet svarer på sin tunneladresse, og adressen du dokumenterte for det, fører ingen steder. Ingenting i OpenVPN-loggen klager, peer-en vises som tilkoblet, og huben lister nøyaktig én klient. Hullet er at en ekstra adresse på en klient er to atskilte fakta: verten må eie den, og huben må vite hvilken peer som eier den. Håndter den ene uten den andre, og trafikken dør enten ved huben eller ankommer uten en rute hjem.

Aliaset er lokalt, eierskapet er eksternt

En tunneladresse forhandles, så begge ender lærer den under håndtrykket. En ekstra tjenesteadresse forhandles ikke i det hele tatt, og derfor endrer det ingenting på huben å legge den til i seg selv. Klienten kan eie adressen med en gang, og serveren sender fortsatt trafikken på standardveien sin eller slipper den. Det må opprettes to poster på to forskjellige steder.

På klienten tilhører adressen verten, og loopback er det naturlige hjemmet for en tjenesteidentitet som aldri bør vises på en fysisk lenke. På huben er peer-til-prefiks-kartleggingen en egen erklæring som bare serveren leser. Ingen av postene forutsetter den andre.

Hold de to områdene atskilt i notatene dine også. Adresser i et eksempel er dokumentasjonsverdier, og å overlappe dem med et ekte LAN er den raskeste måten å få et fungerende oppsett til å se ødelagt ut.

Legg til adressen på klienten varig

Legg tjenesteadressen på loopback med et vertsprefiks, slik at verten behandler den som lokal inngang og ikke som et subnett som skal nås. ip address add 10.66.0.10/32 dev lo gjør det for én adresse, og å gjenta kommandoen for en andre adresse modellerer to tjenester.

Kjør det som en engangstest, og flytt det deretter inn i det som eier vertens nettverkskonfigurasjon, fordi et tillegg under kjøring forsvinner ved omstart, og duplikater hoper seg opp mellom gjentilkoblinger. En systemd-enhet ordnet etter nettverket er ett alternativ, og en distribusjonsnettverksbehandler er et annet. Uansett hva du velger, må adressen finnes før programmet binder seg, ellers starter tjenesten på feil socket. Bekreft med ip address show dev lo etter en omstart og ikke etter den manuelle kommandoen.

Binding er en beslutning atskilt fra adressering. Et program som lytter på hver adresse, godtar trafikk på grensesnitt du aldri mente, så pek det mot den spesifikke tjenesteadressen. Da har den lokale inngangspolicyen noe presist å matche.

Krev den i CCD-filen som huben faktisk leser

På serveren går eierskapserklæringen i filen per klient som velges av det autentiserte fellesnavnet, inne i katalogen som er navngitt av client-config-dir. Linjen er iroute 10.66.0.10 255.255.255.255, én per adresse, og den forteller serveren hvilken peer som skal motta trafikk for den destinasjonen.

To detaljer bryter dette stille. Filnavnet må samsvare med navnet serveren faktisk bruker, som er annerledes når username-as-common-name er med i spillet. Og iroute virker bare i TUN-modus med en konfigurert klientkonfigurasjonskatalog, så samme linje gjør ingenting i en broet utrulling. Legg til linjer i den eksisterende filen i stedet for å erstatte den, siden den kan allerede bære en fast adresse eller push-alternativer. OpenVPN 2.6-referansen dokumenterer både katalogen og eierskapsdirektivet.

Hubens egen kjerne trenger også en vei til disse destinasjonene, slik at lokalt generert trafikk kommer inn i tunnelprosessen. route 10.66.0.10 255.255.255.255 i serverkonfigurasjonen dekker trafikk serveren selv skaper, mens andre klienter trenger push "route 10.66.0.10 255.255.255.255" for å lære destinasjonen selv.

Ruting og autorisasjon forblir atskilt. En pushet rute forteller en klient hvor pakker skal sendes, og gir ingenting; tjenesten må fortsatt godta den kallende parten på sine egne vilkår.

Kontroller inngangspolicy og returveien

En pakke adressert til aliaset ankommer den eide verten som lokal inngang, så spørsmålet er om den lokale brannmuren tillater den kilden og porten. Tillat den spesifikke tjenesteporten fra VPN-kildeområdet i stedet for å åpne hele adressen.

Svar trenger en rute tilbake til den kallende parten. For en kallende part i den vanlige tunnelpoolen finnes den veien allerede, fordi tunnelinnretningen bærer den. En kallende part bak et annet rutet nettverk trenger også returruten til det nettverket, og det er her asymmetriske oppsett mister pakker.

Se opp for en andre lytter på samme port bundet til en annen adresse, fordi kjernen leverer til den socketen som passer, og resultatene ser tilfeldige ut. Kontroller med ss -lntp og bekreft at den bundne adressen er tjenestealiaset. Kilde-NAT er ikke nødvendig her, og å legge det til skjuler identiteten til den kallende parten som loggene dine avhenger av.

Test adresser og eierskap hver for seg

Test i to trinn. Bekreft først at den eide verten kan nå tjenesten på aliaset sitt fra seg selv, noe som skiller bindings- og brannmurproblemer fra ruting. Test deretter fra en ekte VPN-kallende part med programmets egen autentisering. Når det første går gjennom og det andre feiler, er den manglende brikken på hub-siden.

Kontroller også feilmodusene som overlever en tilkobling: aliaset forblir tildelt når tunnelen er nede, og huben beholder ruten sin når peer-en er borte. Ingen av objektene beviser alene at tjenesten er tilgjengelig, og derfor slår totrinnstesten en enkelt ping fra en bærbar PC.