Offentleg prefiks gjennom OpenVPN: reparer returvegen

Sjå korleis tunnelen kjem opp og klienten pingar den andre sida, og deretter svarar ei offentleg adresse som høyrer til bak VPN-en frå ein annan stad, eller ikkje i det heile. Det symptomet har vanlegvis ingenting å gjere med chifferet eller sertifikata. Eit prefiks som leverandøren rutar vert levert som ei IP-rute, og å bere det over OpenVPN tyder å gjenskape ruta på to nivå og halde på kildeadressa på returvegen. Det er ikkje naudsynt å bru WAN-et, og å leggje adressa til eit grensesnitt lagar ikkje den oppstraums ruta.

Prefikset må først rutast til deg

Spør leverandøren korleis blokka vert levert. Eit prefiks som er ruta til hovudadressa til serveren din er noko anna enn adresser som leverandøren ventar å nå direkte på eit WAN-segment. Berre den første modellen fungerer med designet her.

Viss leverandøren rutar 198.51.100.64/28 til inngangsserveren din, kjem pakkar for det området til serveren og stoppar der med mindre du videresender dei. Viss leverandøren i staden brer området over på uplinken din, må serveren svare på ARP for det, som er eit anna problem.

Test leveringsmodellen før du rører OpenVPN: ping ei adresse i blokka frå utsida og sjå kva grensesnitt som tek imot henne. Viss ingenting kjem, hjelper ingen tunnelkonfigurasjon. Viss adressa svarar direkte på WAN-et, brer leverandøren over i staden for å rute, og designet nedanfor gjeld ikkje.

To rutenivå: kjernerute og iroute

OpenVPN treng prefikset på to stader. Kjernen må vite at prefikset høyrer til tunnel-eininga, slik at videresende pakkar går inn i OpenVPN i staden for standardruta. OpenVPN må òg vite kva autentisert klient som eig prefikset, og det er iroute-oppføringa i den klientspesifikke mappa.

Ruta på serversida ser slik ut, med prefikset og maska som må samsvare med tildelinga:

ip route add 198.51.100.64/28 dev tun0

Den klientspesifikke konfigurasjonen tildeler eigarskap. Legg han i CCD-fila som er kalla opp etter klienten sitt sertifikat sitt vanlege namn, og stadfest at nettopp den mappa er den serveren faktisk les:

iroute 198.51.100.64 255.255.255.240

OpenVPN dokumentasjon om ruta nettverk skildrar begge nivåa og kvifor dei er skilde. Ei kjernerute utan iroute sender pakkar inn i tunnelen utan eigar, og OpenVPN kastar dei. Ein iroute utan kjerneruta lèt pakkane bli på standardvegen til serveren. Begge feila ser ut som ein øydelagd tunnel frå klientsida.

Kvar tenesteadressa bur

Det delegerte prefikset er ikkje det same som tunnelens eigne adresser. Nummerer lenkja frå det private rommet viss du vil, og plasser den offentlege tenesteadressa der tenesta faktisk køyrer.

På ein Linux-klient som avsluttar tenesta lokalt, er éi vertsadresse nok:

ip address add 198.51.100.70/32 dev lo

Viss prefikset vert ruta vidare til ein VM-vert eller eit anna LAN, konfigurer i staden den nedstraums vegen og returruta hans. Det er ikkje naudsynt å tildele kvar adresse i blokka til VPN-klienten, og det skapar konfliktar seinare.

Hald den offentlege kjelda på returvegen

Eit svar frå det delegerte prefikset må forlate tunnelen og nå ruta til leverandøren. Viss den eksterne verten sender det via sin eigen ISP, ser kildeadressa forfalska ut, og leverandøren eller destinasjonen kastar det. Løysinga er ein kjeldebasert regel eller ein dedikert rutetabell, ikkje ein breiare NAT. Utan han fungerer tenesta frå tunnelpartnaren og feilar overalt elles.

På inngangsserveren er ein brei masquerade-regel den vanlege skuldige. Han skriv den offentlege kjelda om til hovudadressa til serveren, og klienten ser aldri den ekte:

iptables -t nat -S POSTROUTING

Avgrens NAT til dei private VPN-klientane som treng det, og lat det delegerte prefikset vere utan omsetjing. Stadfest deretter at serveren videresender prefikset i det heile, fordi ei videresendingskjede med standard avvising kastar det lydlaust.

Verifiser begge retningar før du stolar på det

Verifiseringa er fire observasjonar, ikkje éin. Stadfest at ruta til leverandøren kjem, at kjernen sender prefikset inn i tunnelen, at OpenVPN tildeler det til rett klient, og at svaret kjem tilbake med den offentlege kjelda intakt. Kvar observasjon har sin eigen kommando, så ein feil peikar på eit lag i staden for heile designet. Køyr dei i den rekkjefølgja etter kvar konfigurasjonsendring.

Spør kjernen kva bane ei delegert adresse tek, og følg med på tunnelen medan ein førespurnad køyrer:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrering av omvend bane kan oppheve ei korrekt rute. Sjekk den effektive innstillinga på tunnelen og på uplinken, og hugs at ein streng modus avviser trafikk der kjelda ikkje samsvarer med grensesnittet ho kom inn på:

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

Til slutt, test feilsituasjonen. Stopp tunnelen og stadfest at det offentlege prefikset ikkje lek ut gjennom den vanlege uplinken. Å gjenopprette VPN-en skal bringe tenesta tilbake utan å utvide kva portar verten eksponerer.