Javni prefiks kroz OpenVPN: popravite povratni put

Gledajte kako tunel dolazi gore i klijent pinga suprotnu stranu, a onda javna adresa koja pripada iza VPN-a odgovara odnekud drugdje, ili nikako. Taj simptom obično nema veze sa šifrom ili certifikatima. Prefiks koji ruterira provajder dostavlja se kao IP ruta, a prenošenje preko OpenVPN znači reproducirati tu rutu na dva nivoa i sačuvati izvornu adresu na povratnom putu. Premošćavanje WAN-a nije potrebno, a dodavanje adrese na interfejs ne stvara uzvodnu rutu.

Prefiks prvo mora biti rutiran do vas

Pitajte provajdera kako se blok dostavlja. Prefiks rutiran na glavnu adresu vašeg servera je druga stvar od adresa koje provajder očekuje da dosegne direktno na WAN segmentu. Samo prvi model radi s ovim dizajnom.

Ako provajder rutira 198.51.100.64/28 na vaš ulazni server, paketi za taj opseg dolaze na server i tu se zaustavljaju osim ako ih ne prosljeđujete. Ako provajder umjesto toga premosti opseg na vaš uplink, server mora odgovoriti na ARP za njega, što je drugi problem.

Testirajte model dostave prije nego što dirate OpenVPN: izvana pingajte adresu u bloku i gledajte koji je interfejs prima. Ako ništa ne dolazi, nikakva konfiguracija tunela neće pomoći. Ako adresa odgovara direktno na WAN-u, provajder premošćuje umjesto da rutira, i dizajn ispod se ne primjenjuje.

Dva nivoa rutiranja: kernel ruta i iroute

OpenVPN-u treba prefiks na dva mjesta. Kernel mora znati da prefiks pripada tunelskom uređaju, da bi proslijeđeni paketi ušli u OpenVPN umjesto u podrazumijevanu rutu. OpenVPN također mora znati koji autentificirani klijent posjeduje prefiks, a to je iroute unos u direktoriju specifičnom za klijenta.

Ruta na strani servera izgleda ovako, pri čemu prefiks i maska moraju odgovarati dodjeli:

ip route add 198.51.100.64/28 dev tun0

Konfiguracija specifična za klijenta dodjeljuje vlasništvo. Stavite je u CCD datoteku nazvanu po zajedničkom imenu klijentskog certifikata i potvrdite da je taj direktorij onaj koji server zaista čita:

iroute 198.51.100.64 255.255.255.240

Dokumentacija OpenVPN o rutiranim mrežama opisuje oba nivoa i zašto su odvojeni. Kernel ruta bez iroute šalje pakete u tunel bez vlasnika, i OpenVPN ih odbacuje. iroute bez kernel rute ostavlja pakete na podrazumijevanoj putanji servera. Obje greške izgledaju s klijentske strane kao pokvaren tunel.

Gdje živi servisna adresa

Delegirani prefiks nije isto što i vlastite adrese tunela. Numerišite vezu iz privatnog prostora ako želite, i smjestite javnu servisnu adresu tamo gdje servis zaista radi.

Na Linux klijentu koji lokalno terminira servis, dovoljna je jedna adresa hosta:

ip address add 198.51.100.70/32 dev lo

Ako se prefiks dalje rutira na VM host ili drugi LAN, umjesto toga konfigurirajte tu nizvodnu putanju i njenu povratnu rutu. Dodjeljivanje svake adrese u bloku VPN klijentu nije potrebno i kasnije stvara sukobe.

Sačuvajte javni izvor na povratnom putu

Odgovor s delegiranog prefiksa mora izaći kroz tunel i doći do provajderove rute. Ako ga udaljeni host pošalje preko vlastitog ISP-a, izvorna adresa izgleda lažno, i provajder ili odredište ga odbacuju. Rješenje je pravilo zasnovano na izvoru ili namjenska tablica rutiranja, ne širi NAT. Bez njega servis radi s tunelskog partnera i pada sa svih drugih mjesta.

Na ulaznom serveru široko masquerade pravilo je uobičajeni krivac. Ono prepisuje javni izvor na glavnu adresu servera, i klijent nikada ne vidi pravi:

iptables -t nat -S POSTROUTING

Ograničite NAT na privatne VPN klijente kojima je potreban i ostavite delegirani prefiks nepreveden. Zatim potvrdite da server uopće prosljeđuje prefiks, jer lanac prosljeđivanja sa zabranom po defaultu ga tiho odbacuje.

Provjerite oba smjera prije nego što mu vjerujete

Provjera je četiri opažanja, ne jedno. Potvrdite da provajderova ruta stiže, kernel šalje prefiks u tunel, OpenVPN ga pripisuje pravom klijentu, i odgovor se vraća s netaknutim javnim izvorom. Svako opažanje ima svoju naredbu, pa neuspjeh pokazuje na sloj, a ne na cijeli dizajn. Pokrenite ih tim redom nakon svake promjene konfiguracije.

Pitajte kernel koju putanju zauzima delegirana adresa, i gledajte tunel dok zahtjev radi:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtriranje povratnog puta može poništiti ispravnu rutu. Provjerite efektivnu postavku na tunelu i na uplinku, i zapamtite da strogi režim odbacuje saobraćaj čiji izvor ne odgovara interfejsu na koji je stigao:

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

Na kraju, testirajte slučaj kvara. Zaustavite tunel i potvrdite da javni prefiks ne curi kroz obični uplink. Vraćanje VPN-a treba vratiti servis bez proširivanja portova koje host izlaže.