Offentlig prefiks gjennom OpenVPN: reparer returveien

Se tunnelen komme opp og klienten pinge den andre siden, og deretter svarer en offentlig adresse som hører til bak VPN-en fra et annet sted, eller ikke i det hele tatt. Det symptomet har vanligvis ingenting å gjøre med chifferet eller sertifikatene. Et prefiks som leverandøren ruter leveres som en IP-rute, og å bære det over OpenVPN betyr å gjenskape ruten på to nivåer og bevare kildeadressen på returveien. Det er ikke nødvendig å bro WAN-et, og å legge adressen til et grensesnitt lager ikke den oppstrøms ruten.

Prefikset må først rutes til deg

Spør leverandøren hvordan blokken leveres. Et prefiks som rutes til serverens hovedadresse er noe annet enn adresser som leverandøren forventer å nå direkte på et WAN-segment. Bare den første modellen fungerer med designet her.

Hvis leverandøren ruter 198.51.100.64/28 til inngangsserveren din, kommer pakker for det området til serveren og stopper der med mindre du videresender dem. Hvis leverandøren i stedet brer området over på uplinken din, må serveren svare på ARP for det, som er et annet problem.

Test leveringsmodellen før du rører OpenVPN: ping en adresse i blokken fra utsiden og se hvilket grensesnitt som mottar den. Hvis ingenting kommer, hjelper ingen tunnelkonfigurasjon. Hvis adressen svarer direkte på WAN-et, brer leverandøren over i stedet for å rute, og designet nedenfor gjelder ikke.

To rutenivåer: kjernerute og iroute

OpenVPN trenger prefikset på to steder. Kjernen må vite at prefikset tilhører tunnel-enheten, slik at videresendte pakker går inn i OpenVPN i stedet for standardruten. OpenVPN må også vite hvilken autentisert klient som eier prefikset, og det er iroute-oppføringen i den klientspesifikke katalogen.

Ruten på serversiden ser slik ut, med prefikset og masken som må samsvare med tildelingen:

ip route add 198.51.100.64/28 dev tun0

Den klientspesifikke konfigurasjonen tildeler eierskap. Legg den i CCD-filen som er oppkalt etter klientens sertifikatets vanlige navn, og bekreft at nettopp den katalogen er den serveren faktisk leser:

iroute 198.51.100.64 255.255.255.240

OpenVPN dokumentasjon om rutede nettverk beskriver begge nivåene og hvorfor de er adskilt. En kjernerute uten iroute sender pakker inn i tunnelen uten eier, og OpenVPN forkaster dem. En iroute uten kjerneruten lar pakkene bli på serverens standardvei. Begge feilene ser ut som en ødelagt tunnel fra klientsiden.

Hvor tjenesteadressen bor

Det delegerte prefikset er ikke det samme som tunnelens egne adresser. Nummerer lenken fra det private rommet hvis du vil, og plasser den offentlige tjenesteadressen der tjenesten faktisk kjører.

På en Linux-klient som avslutter tjenesten lokalt, er én vertsadresse nok:

ip address add 198.51.100.70/32 dev lo

Hvis prefikset rutes videre til en VM-vert eller et annet LAN, konfigurer i stedet den nedstrøms banen og returruten dens. Det er ikke nødvendig å tildele hver adresse i blokken til VPN-klienten, og det skaper konflikter senere.

Behold den offentlige kilden på returveien

Et svar fra det delegerte prefikset må forlate tunnelen og nå leverandørens rute. Hvis den eksterne verten sender det via sin egen ISP, ser kildeadressen forfalsket ut, og leverandøren eller destinasjonen forkaster det. Løsningen er en kildebasert regel eller en dedikert rutetabell, ikke en bredere NAT. Uten den fungerer tjenesten fra tunnelpartneren og feiler overalt ellers.

På inngangsserveren er en bred masquerade-regel den vanlige skyldige. Den skriver den offentlige kilden om til serverens hovedadresse, og klienten ser aldri den ekte:

iptables -t nat -S POSTROUTING

Begrens NAT til de private VPN-klientene som trenger det, og la det delegerte prefikset være uoversatt. Bekreft deretter at serveren videresender prefikset i det hele tatt, fordi en videresendingskjede med standard avvisning forkaster det lydløst.

Verifiser begge retninger før du stoler på det

Verifiseringen er fire observasjoner, ikke én. Bekreft at leverandørens rute kommer, at kjernen sender prefikset inn i tunnelen, at OpenVPN tilordner det til riktig klient, og at svaret kommer tilbake med den offentlige kilden intakt. Hver observasjon har sin egen kommando, så en feil peker på et lag i stedet for hele designet. Kjør dem i den rekkefølgen etter hver konfigurasjonsendring.

Spør kjernen hvilken bane en delegert adresse tar, og følg med på tunnelen mens en forespørsel kjører:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrering av omvendt bane kan oppheve en korrekt rute. Sjekk den effektive innstillingen på tunnelen og på uplinken, og husk at en streng modus avviser trafikk der kilden ikke samsvarer med grensesnittet den kom inn på:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Til slutt, test feilsituasjonen. Stopp tunnelen og bekreft at det offentlige prefikset ikke lekker ut gjennom den vanlige uplinken. Å gjenopprette VPN-en skal bringe tjenesten tilbake uten å utvide hvilke porter verten eksponerer.