Verejný prefix cez OpenVPN: opraviť spiatočnú cestu

Sledujte, ako tunel naskočí a klient pinguje druhú stranu, a potom verejná adresa, ktorá patrí za VPN, odpovedá odinakiaľ, alebo vôbec. Tento príznak zvyčajne nemá nič spoločné so šifrou ani s certifikátmi. Prefix smerovaný poskytovateľom sa dodáva ako IP trasa, a preniesť ho cez OpenVPN znamená reprodukovať túto trasu na dvoch úrovniach a zachovať zdrojovú adresu na spiatočnej ceste. Premosťovať WAN nie je potrebné a pridanie adresy na rozhranie nevytvorí nadradenú trasu.

Prefix musí byť najprv smerovaný k vám

Opýtajte sa poskytovateľa, ako sa blok dodáva. Prefix smerovaný na hlavnú adresu vášho servera je iná vec než adresy, ktoré poskytovateľ očakáva priamo na WAN segmente. S týmto návrhom funguje len prvý model.

Ak poskytovateľ smeruje 198.51.100.64/28 na váš vstupný server, pakety pre tento rozsah dorazia na server a tam sa zastavia, ak ich nepreposielate. Ak poskytovateľ rozsah namiesto toho premostí na váš uplink, server musí na ARP preň odpovedať, čo je iný problém.

Otestujte model dodania, skôr než sa dotknete OpenVPN: zvonku pingnite adresu v bloku a sledujte, ktoré rozhranie ju prijme. Ak nič nedorazí, žiadna konfigurácia tunela nepomôže. Ak adresa odpovedá priamo na WAN, poskytovateľ premostí namiesto smerovania a návrh nižšie neplatí.

Dve úrovne smerovania: trasa v jadre a iroute

OpenVPN potrebuje prefix na dvoch miestach. Jadro musí vedieť, že prefix patrí tunelovému zariadeniu, aby preposielané pakety vstúpili do OpenVPN namiesto predvolenej trasy. OpenVPN tiež musí vedieť, ktorý autentizovaný klient prefix vlastní, a to je záznam iroute v adresári špecifickom pre klienta.

Trasa na strane servera vyzerá takto, pričom prefix a maska musia zodpovedať prideleniu:

ip route add 198.51.100.64/28 dev tun0

Konfigurácia špecifická pre klienta priraďuje vlastníctvo. Vložte ju do súboru CCD pomenovaného podľa bežného názvu klientskeho certifikátu a overte, že práve tento adresár server skutočne číta:

iroute 198.51.100.64 255.255.255.240

Dokumentácia OpenVPN o smerovaných sieťach opisuje obe úrovne a prečo sú oddelené. Trasa v jadre bez iroute posiela pakety do tunela bez vlastníka a OpenVPN ich zahadzuje. iroute bez trasy v jadre necháva pakety na predvolenej ceste servera. Obe chyby vyzerajú z klientskej strany ako pokazený tunel.

Kde žije adresa služby

Delegovaný prefix nie je to isté ako vlastné adresy tunela. Očíslujte prepojenie z privátneho priestoru, ak chcete, a umiestnite verejnú adresu služby tam, kde služba skutočne beží.

Na klientovi Linux, ktorý službu ukončuje lokálne, stačí jedna adresa hostiteľa:

ip address add 198.51.100.70/32 dev lo

Ak sa prefix smeruje ďalej na hostiteľa VM alebo inú LAN, nakonfigurujte namiesto toho túto cestu po prúde a jej spiatočnú trasu. Priraďovať každú adresu v bloku klientovi VPN nie je potrebné a neskôr vytvára konflikty.

Zachovajte verejný zdroj na spiatočnej ceste

Odpoveď z delegovaného prefixu musí vyjsť tunelom a dosiahnuť trasu poskytovateľa. Ak ju vzdialený hostiteľ pošle cez svojho ISP, zdrojová adresa vyzerá podvrhnutá a poskytovateľ alebo cieľ ju zahodí. Riešením je pravidlo založené na zdroji alebo vyhradená smerovacia tabuľka, nie širší NAT. Bez nej služba funguje od partnera tunela a zlyháva všade inde.

Na vstupnom serveri je široké pravidlo masquerade obvyklý vinník. Prepisuje verejný zdroj na hlavnú adresu servera a klient ten skutočný nikdy nevidí:

iptables -t nat -S POSTROUTING

Obmedzte NAT na privátnych klientov VPN, ktorí ho potrebujú, a delegovaný prefix nechajte nepreložený. Potom overte, že server prefix vôbec preposiela, pretože preposielací reťazec so zakázaním podľa predvoleného nastavenia ho ticho zahadzuje.

Overte oba smery, skôr než tomu budete veriť

Overenie sú štyri pozorovania, nie jedno. Overte, že trasa poskytovateľa dorazí, jadro pošle prefix do tunela, OpenVPN ho priradí správnemu klientovi a odpoveď sa vráti s neporušeným verejným zdrojom. Každé pozorovanie má svoj príkaz, takže zlyhanie ukazuje na vrstvu, nie na celý návrh. Spúšťajte ich v tomto poradí po každej zmene konfigurácie.

Opýtajte sa jadra, ktorou cestou sa delegovaná adresa vydá, a sledujte tunel, kým beží požiadavka:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrovanie spätnej cesty môže zrušiť správnu trasu. Skontrolujte efektívne nastavenie na tuneli a na uplinku a pamätajte, že striktný režim odmieta prevádzku, ktorej zdroj nezodpovedá rozhraniu, na ktoré dorazila:

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

Nakoniec otestujte prípad zlyhania. Zastavte tunel a overte, že verejný prefix neuniká bežným uplinkom. Obnovenie VPN by malo vrátiť službu bez rozšírenia portov, ktoré hostiteľ otvára.