Iepenbier prefiks fia OpenVPN: de weromwei reparearje

Sjoch hoe’t de tunnel omheech komt en de klient de oare kant pinget, en dan antwurdet in iepenbier adres dat efter de VPN heart fan earne oars, of hielendal net. Dat symptoom hat meastentiids neat te meitsjen mei de sjifre of de sertifikaten. In prefiks dat de provider rûtet, wurdt as in IP-rûte levere, en it oer OpenVPN drage betsjut dy rûte op twa nivo’s wer te meitsjen en it boarne-adres op de weromwei te bewarjen. De WAN oerbrikke is net nedich, en it adres oan in ynterface taheakje makket de boppeste rûte net.

It prefiks moat earst nei jo ta rûte wurde

Freegje de provider hoe’t it blok levere wurdt. In prefiks dat nei it haadadres fan jo tsjinner rûte wurdt, is wat oars as adressen dy’t de provider ferwachtet direkt op in WAN-segment te berikken. Allinnich it earste model wurket mei it ûntwerp hjir.

As de provider 198.51.100.64/28 nei jo yngongstsjinjer rûtet, komme pakketten foar dat berik by de tsjinner oan en stopje dêr, útsein as jo se trochstjoere. As de provider it berik ynstee oer jo uplink oerbrikt, moat de tsjinner dêrfoar ARP beantwurdzje, wat in oar probleem is.

Test it leveringsmodel foardat jo OpenVPN oanreitsje: ping fan bûten in adres yn it blok en sjoch hokker ynterface it ûntfangt. As der neat oankomt, helpt gjin inkele tunnelkonfiguraasje. As it adres direkt op de WAN antwurdet, oerbrikt de provider ynstee fan te rûten, en it ûntwerp hjirûnder jildt net.

Twa rûtenivo’s: kernelrûte en iroute

OpenVPN hat it prefiks op twa plakken nedich. De kernel moat witte dat it prefiks by it tunnelapparaat heart, sadat trochstjoerde pakketten OpenVPN yngean ynstee fan de standertrûte. OpenVPN moat ek witte hokker autentisearre klient it prefiks besit, en dat is de iroute-ynskriuwing yn de kliïntspesifike map.

De rûte oan de tsjinnerkant sjocht der sa út, mei it prefiks en masker dat by de tawizing past:

ip route add 198.51.100.64/28 dev tun0

De kliïntspesifike konfiguraasje jout eigendom. Set it yn it CCD-bestân dat neamd is nei de mienskiplike namme fan it kliïntsertifikaat, en befêstigje dat dy map dejinge is dy’t de tsjinner echt lêst:

iroute 198.51.100.64 255.255.255.240

De OpenVPN-dokumintaasje oer rûte netwurken beskriuwt beide nivo’s en wêrom’t se apart binne. In kernelrûte sûnder iroute stjoert pakketten sûnder eigner de tunnel yn, en OpenVPN smyt se fuort. In iroute sûnder de kernelrûte lit pakketten op it standertpaad fan de tsjinner. Beide flaters lykje fan de kliïntkant as in brutsen tunnel.

Wêr’t it tsjinstadres wennet

It delegrearre prefiks is net itselde ding as de eigen adressen fan de tunnel. Nûmerje de keppeling út de partikuliere romte as jo wolle, en pleatst it iepenbiere tsjinstadres dêr’t de tsjinst echt rint.

Op in Linux-klient dy’t de tsjinst lokaal beëiniget, is ien hostadres genôch:

ip address add 198.51.100.70/32 dev lo

As it prefiks fierder rûte wurdt nei in VM-host of in oar LAN, konfigurearje dan ynstee dat delstreampaad en syn weromrûte. It is net nedich om elk adres yn it blok oan de VPN-klient ta te wizen, en it makket letter konflikten.

Hâld de iepenbiere boarne op de weromwei

In antwurd út it delegrearre prefiks moat troch de tunnel nei bûten gean en de rûte fan de provider berikke. As de fiere host it fia syn eigen ISP stjoert, liket it boarne-adres ferfalske, en de provider of de bestimming smyt it fuort. De oplossing is in boarne-basearre regel of in tawijd rûtetabel, net in breder NAT. Sûnder dat wurket de tsjinst fan de tunnelpartner en mislearret fan oeral oars.

By de yngongstsjinjer is in brede masquerade-regel de gewoane skuldige. It skriuwt de iepenbiere boarne oer nei it haadadres fan de tsjinner, en de klient sjocht nea de echte:

iptables -t nat -S POSTROUTING

Behein NAT ta de partikuliere VPN-kliïnten dy’t it nedich hawwe en lit it delegrearre prefiks ûnoerset. Befêstigje dan dat de tsjinner it prefiks hielendal trochstjoert, want in trochstjoerkeatling dy’t standert wegeret smyt it stil fuort.

Ferifiearje beide rjochtingen foardat jo it fertrouwe

Ferifikaasje binne fjouwer observaasjes, net ien. Befêstigje dat de rûte fan de provider oankomt, de kernel it prefiks de tunnel yn stjoert, OpenVPN it oan de juste klient taskriuwt, en it antwurd mei de iepenbiere boarne yntakt weromkomt. Eltse observaasje hat syn eigen kommando, sadat in mislearring nei in laach wiist ynstee fan it hiele ûntwerp. Rin se yn dy folchoarder nei eltse konfiguraasjeferoaring.

Freegje de kernel hokker paad in delegrearre adres nimt, en hâld de tunnel yn ‘e gaten wylst in fersyk rint:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtering fan de omkearde wei kin in korrekte rûte ûngedien meitsje. Kontrolearje de effektive ynstelling op de tunnel en op de uplink, en tink derom dat in strikte modus ferkear wegeret wêrfan’t de boarne net by it ynterface past dêr’t it oankaam:

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

Test úteinlik it gefal fan mislearring. Stop de tunnel en befêstigje dat it iepenbiere prefiks net út ‘e gewoane uplink lekt. It werstellen fan de VPN heart de tsjinst werom te bringen sûnder te ferbredzjen hokker poarten de host iepenet.