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

Programmet svarer på sin tunneladresse, og den adresse, du har dokumenteret til det, fører ingen steder hen. Intet i OpenVPN-loggen klager, peer’en vises som forbundet, og hubben lister præcis én klient. Hullet er, at en ekstra adresse på en klient er to adskilte kendsgerninger: værten skal eje den, og hubben skal vide, hvilken peer der ejer den. Klar den ene uden den anden, og trafikken dør enten ved hubben eller ankommer uden en rute hjem.

Aliaset er lokalt, ejerskabet er fjernt

En tunneladresse forhandles, så begge ender lærer den under håndtrykket. En ekstra tjenesteadresse forhandles slet ikke, og derfor ændrer det intet på hubben i sig selv at tilføje den. Klienten kan eje adressen med det samme, og serveren sender stadig trafikken ad sin standardvej eller dropper den. Der skal oprettes to poster på to forskellige steder.

På klienten tilhører adressen værten, og loopback er det naturlige hjem for en tjenesteidentitet, der aldrig bør optræde på et fysisk link. På hubben er peer-til-præfiks-kortlægningen en særskilt erklæring, som kun serveren læser. Ingen af de to poster forudsætter den anden.

Hold de to områder adskilt i dine noter også. Adresser i et eksempel er dokumentationsværdier, og at overlappe dem med et rigtigt LAN er den hurtigste måde at få en fungerende opsætning til at se brudt ud.

Tilføj adressen på klienten varigt

Læg tjenesteadressen på loopback med et værtspræfiks, så værten behandler den som lokalt input frem for som et undernet, der skal nås. ip address add 10.66.0.10/32 dev lo gør det for én adresse, og at gentage kommandoen for en anden adresse modellerer to tjenester.

Kør det som en engangstest, og flyt det derefter ind i det, der ejer værtens netværkskonfiguration, fordi en tilføjelse under kørsel forsvinder ved genstart, og dubletter hober sig op mellem genforbindelser. En systemd-enhed ordnet efter netværket er en mulighed, og en distributionsnetværksadministrator er en anden. Uanset hvad du vælger, skal adressen findes, før programmet binder, ellers starter tjenesten på den forkerte socket. Bekræft med ip address show dev lo efter en genstart i stedet for efter den manuelle kommando.

Binding er en beslutning adskilt fra adressering. Et program, der lytter på alle adresser, accepterer trafik på grænseflader, du aldrig havde tænkt på, så peg det mod den specifikke tjenesteadresse. Så har den lokale inputpolitik noget præcist at matche.

Kræv den i den CCD-fil, som hubben faktisk læser

På serveren går ejerskabserklæringen i den per-klient-fil, som det godkendte fælles navn vælger, inde i mappen angivet af client-config-dir. Linjen er iroute 10.66.0.10 255.255.255.255, én per adresse, og den fortæller serveren, hvilken peer der skal modtage trafik til den destination.

To detaljer bryder dette lydløst. Filnavnet skal matche det navn, serveren faktisk bruger, hvilket er forskelligt, når username-as-common-name er i spil. Og iroute virker kun i TUN-tilstand med en konfigureret klientkonfigurationsmappe, så samme linje gør intet i en broet udrulning. Føj linjer til den eksisterende fil i stedet for at erstatte den, da den måske allerede bærer en fast adresse eller push-indstillinger. OpenVPN 2.6-referencen dokumenterer både mappen og ejerskabsdirektivet.

Hubbens egen kerne har også brug for en vej til de destinationer, så lokalt genereret trafik kommer ind i tunnelprocessen. route 10.66.0.10 255.255.255.255 i serverkonfigurationen dækker trafik, som serveren selv starter, mens andre klienter har brug for push "route 10.66.0.10 255.255.255.255" for selv at lære destinationen.

Ruting og autorisation forbliver adskilt. En pushet rute fortæller en klient, hvor pakker skal sendes hen, og giver intet; tjenesten skal stadig acceptere den kaldende part på sine egne vilkår.

Kontrollér inputpolitik og svarruten

En pakke adresseret til aliaset ankommer til den ejende vært som lokalt input, så spørgsmålet er, om den lokale firewall tillader den kilde og port. Tillad den specifikke tjenesteport fra VPN-kildeområdet i stedet for at åbne hele adressen.

Svar har brug for en rute tilbage til den kaldende part. For en kaldende part i den normale tunnelpulje findes den vej allerede, fordi tunnelanordningen bærer den. En kaldende part bag et andet rutet netværk har også brug for det netværks returrute, og det er her, asymmetriske opsætninger taber pakker.

Hold øje med en anden lytter på samme port bundet til en anden adresse, fordi kernen leverer til den socket, der matcher, og resultaterne ser tilfældige ud. Kontrollér med ss -lntp og bekræft, at den bundne adresse er tjenestealiaset. Kilde-NAT er ikke nødvendig her, og at tilføje det skjuler den kaldendes identitet, som dine logfiler afhænger af.

Test adresser og ejerskab hver for sig

Test i to trin. Bekræft først, at den ejende vært kan nå tjenesten på sit alias fra sig selv, hvilket adskiller bindings- og firewallproblemer fra ruting. Test derefter fra en rigtig VPN-kaldende part med programmets egen godkendelse. Når det første består, og det andet fejler, er den manglende brik på hub-siden.

Kontrollér også de fejltilstande, der overlever en forbindelse: aliaset forbliver tildelt, når tunnelen er nede, og hubben beholder sin rute, når peer’en er fraværende. Ingen af objekterne beviser alene, at tjenesten kan nås, og derfor slår to-trins-testen et enkelt ping fra en bærbar.