Två tjänsteadresser på en OpenVPN-klient: iroute och lo

Programmet svarar på sin tunneladress, och adressen du dokumenterade för det leder ingenstans. Ingenting i OpenVPN-loggen klagar, peeren visas som ansluten och hubben listar exakt en klient. Gapet är att en andra adress på en klient är två separata fakta: värden måste äga den, och hubben måste veta vilken peer som äger den. Hantera det ena utan det andra och trafiken dör antingen vid hubben eller anländer utan väg hem.

Aliaset är lokalt, ägandet är avlägset

En tunneladress förhandlas, så båda ändarna lär sig den under handskakningen. En extra tjänsteadress förhandlas inte alls, vilket är varför det inte ändrar något på hubben i sig att lägga till den. Klienten kan äga adressen direkt och servern skickar fortfarande den trafiken på sin standardväg eller släpper den. Det måste skapas två poster på två olika ställen.

På klienten tillhör adressen värden, och loopback är det naturliga hemmet för en tjänsteidentitet som aldrig bör synas på en fysisk länk. På hubben är peer-till-prefix-mappningen en separat deklaration som bara servern läser. Ingen av posterna förutsätter den andra.

Håll de två intervallen åtskilda i dina anteckningar också. Adresser i ett exempel är dokumentationsvärden, och att överlappa dem med ett riktigt LAN är det snabbaste sättet att få en fungerande uppsättning att se trasig ut.

Lägg till adressen på klienten varaktigt

Placera tjänsteadressen på loopback med ett värdprefix, så att värden behandlar den som lokal indata och inte som ett subnät som ska nås. ip address add 10.66.0.10/32 dev lo gör det för en adress, och att upprepa kommandot för en andra adress modellerar två tjänster.

Kör det som ett engångstest och flytta det sedan in i det som äger värdens nätverkskonfiguration, eftersom ett tillägg under körning försvinner vid omstart och dubbletter samlas mellan återanslutningar. En systemd-enhet ordnad efter nätverket är ett alternativ, och en distributionsnätverkshanterare är ett annat. Vad du än väljer måste adressen finnas innan programmet binder, annars startar tjänsten på fel socket. Verifiera med ip address show dev lo efter en omstart och inte efter det manuella kommandot.

Bindning är ett beslut skilt från adressering. Ett program som lyssnar på varje adress accepterar trafik på gränssnitt du aldrig avsåg, så peka det mot den specifika tjänsteadressen. Då har den lokala indatapolicyn något exakt att matcha.

Kräv den i CCD-filen som hubben faktiskt läser

På servern går ägandeklarationen in i filen per klient som väljs av det autentiserade gemensamma namnet, inne i katalogen som namnges av client-config-dir. Raden är iroute 10.66.0.10 255.255.255.255, en per adress, och den talar om för servern vilken peer som ska ta emot trafik för den destinationen.

Två detaljer bryter detta tyst. Filnamnet måste matcha namnet som servern faktiskt använder, vilket skiljer sig när username-as-common-name är i spel. Och iroute gäller bara i TUN-läge med en konfigurerad klientkonfigurationskatalog, så samma rad gör ingenting i en bryggd distribution. Lägg till rader i den befintliga filen i stället för att ersätta den, eftersom den redan kan bära en fast adress eller push-alternativ. OpenVPN 2.6-referensen dokumenterar både katalogen och ägandedirektivet.

Hubbens egen kärna behöver också en väg till dessa destinationer, så att lokalt genererad trafik kommer in i tunnelprocessen. route 10.66.0.10 255.255.255.255 i serverkonfigurationen täcker trafik som servern själv skapar, medan andra klienter behöver push "route 10.66.0.10 255.255.255.255" för att lära sig destinationen själva.

Routing och auktorisering förblir åtskilda. En pushad rutt berättar för en klient vart paketen ska skickas och beviljar ingenting; tjänsten måste fortfarande acceptera anroparen på sina egna villkor.

Kontrollera indatapolicyn och returvägen

Ett paket adresserat till aliaset anländer till den ägande värden som lokal indata, så frågan är om den lokala brandväggen tillåter den källan och porten. Tillåt den specifika tjänsteporten från VPN-källområdet i stället för att öppna hela adressen.

Svar behöver en väg tillbaka till anroparen. För en anropare i den vanliga tunnelpoolen finns den vägen redan, eftersom tunnelenheten bär den. En anropare bakom ett annat routat nätverk behöver också returvägen för det nätverket, och det är här asymmetriska uppsättningar tappar paket.

Se upp för en andra lyssnare på samma port bunden till en annan adress, eftersom kärnan levererar till den socket som matchar och resultaten ser slumpmässiga ut. Kontrollera med ss -lntp och bekräfta att den bundna adressen är tjänstealiaset. Käll-NAT behövs inte här, och att lägga till det döljer anroparens identitet som dina loggar bygger på.

Testa adresser och ägande separat

Testa i två steg. Bekräfta först att den ägande värden kan nå tjänsten på sitt alias från sig själv, vilket skiljer bindnings- och brandväggsproblem från routing. Testa sedan från en riktig VPN-anropare med programmets egen autentisering. När det första går igenom och det andra misslyckas finns den saknade biten på hubbsidan.

Kontrollera också de fellägen som överlever en anslutning: aliaset förblir tilldelat när tunneln är nere, och hubben behåller sin rutt när peeren saknas. Inget objekt bevisar ensamt att tjänsten är nåbar, och därför slår tvåstegstestet en enda ping från en bärbar dator.