Offentligt præfiks gennem OpenVPN: ret returvejen

Se tunnelen komme op, og klienten pinge den anden side, og derefter svarer en offentlig adresse, der hører til bag VPN’en, fra et helt andet sted, eller slet ikke. Det symptom har normalt intet at gøre med chifferen eller certifikaterne. Et præfiks, som udbyderen router, leveres som en IP-rute, og at bære det over OpenVPN betyder at genskabe ruten på to niveauer og bevare kildeadressen på returvejen. Det er ikke nødvendigt at bridge WAN’et, og at tilføje adressen til en grænseflade skaber ikke den opstrøms rute.

Præfikset skal først routes til dig

Spørg udbyderen, hvordan blokken leveres. Et præfiks, der routes til din servers hovedadresse, er noget andet end adresser, som udbyderen forventer at nå direkte på et WAN-segment. Kun den første model fungerer med designet her.

Hvis udbyderen router 198.51.100.64/28 til din indgangsserver, ankommer pakker til det område på serveren og stopper der, medmindre du videresender dem. Hvis udbyderen i stedet bridger området til dit uplink, skal serveren svare på ARP for det, hvilket er et andet problem.

Test leveringsmodellen, før du rører ved OpenVPN: ping udefra en adresse i blokken, og se hvilken grænseflade der modtager den. Hvis intet ankommer, hjælper ingen mængde tunnelkonfiguration. Hvis adressen svarer direkte på WAN’et, bridger udbyderen i stedet for at route, og designet nedenfor gælder ikke.

To routingniveauer: kernelrute og iroute

OpenVPN har brug for præfikset to steder. Kernen skal vide, at præfikset hører til tunneenheden, så videresendte pakker går ind i OpenVPN i stedet for standardruten. OpenVPN skal også vide, hvilken autentificeret klient der ejer præfikset, og det er iroute-posten i den klientspecifikke mappe.

Ruten på serversiden ser sådan ud, hvor præfiks og maske skal matche tildelingen:

ip route add 198.51.100.64/28 dev tun0

Den klientspecifikke konfiguration tildeler ejerskab. Læg den i CCD-filen, der er opkaldt efter klientcertifikatets fælles navn, og bekræft, at netop den mappe er den, serveren faktisk læser:

iroute 198.51.100.64 255.255.255.240

OpenVPN’s dokumentation om routedede netværk beskriver begge niveauer og hvorfor de er adskilte. En kernelrute uden iroute sender pakker ind i tunnelen uden ejer, og OpenVPN kasserer dem. En iroute uden kernelruten lader pakkerne blive på serverens standardsti. Begge fejl ser ud som en brudt tunnel fra klientsiden.

Hvor serviceadressen bor

Det delegerede præfiks er ikke det samme som tunnelens egne adresser. Nummerér linket fra det private rum, hvis du vil, og placér den offentlige serviceadresse, hvor tjenesten faktisk kører.

På en Linux-klient, der afslutter tjenesten lokalt, er en enkelt værtsadresse nok:

ip address add 198.51.100.70/32 dev lo

Hvis præfikset routes videre til en VM-vært eller et andet LAN, så konfigurér i stedet den nedstrøms sti og dens returrute. Det er ikke nødvendigt at tildele hver adresse i blokken til VPN-klienten, og det skaber konflikter senere.

Bevar den offentlige kilde på returvejen

Et svar fra det delegerede præfiks skal forlade tunnelen og nå udbyderens rute. Hvis fjernværten sender det via sin egen ISP, ser kildeadressen forfalsket ud, og udbyderen eller destinationen kasserer det. Løsningen er en kildebaseret regel eller en dedikeret routingtabel, ikke en bredere NAT. Uden den virker tjenesten fra tunnelpartneren og fejler overalt ellers.

På indgangsserveren er en bred masquerade-regel den sædvanlige synder. Den omskriver den offentlige kilde til serverens hovedadresse, og klienten ser aldrig den rigtige:

iptables -t nat -S POSTROUTING

Begræns NAT til de private VPN-klienter, der har brug for det, og lad det delegerede præfiks være uoversat. Bekræft derefter, at serveren overhovedet videresender præfikset, for en videresendelseskæde med standardafvisning kasserer det lydløst.

Verificér begge retninger, før du stoler på det

Verifikation er fire observationer, ikke én. Bekræft, at udbyderens rute ankommer, at kernen sender præfikset ind i tunnelen, at OpenVPN tildeler det til den rigtige klient, og at svaret vender tilbage med den offentlige kilde intakt. Hver observation har sin egen kommando, så en fejl peger på et lag i stedet for hele designet. Kør dem i den rækkefølge efter hver konfigurationsændring.

Spørg kernen, hvilken sti en delegeret adresse tager, og hold øje med tunnelen, mens en anmodning kører:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrering af omvendt sti kan annullere en korrekt rute. Tjek den effektive indstilling på tunnelen og på uplink’et, og husk, at en streng tilstand afviser trafik, hvis kilde ikke matcher den grænseflade, den ankom på:

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

Til sidst, test fejltilfældet. Stop tunnelen, og bekræft at det offentlige præfiks ikke lækker ud ad det almindelige uplink. Gendannelse af VPN’en bør bringe tjenesten tilbage uden at udvide, hvilke porte værten eksponerer.