Prefiksi publik përmes OpenVPN: rregullo rrugën e kthimit

Shikoni tunelin duke u ngritur dhe klientin duke bërë ping në anën tjetër, dhe pastaj një adresë publike që i përket pas VPN-së përgjigjet nga diku tjetër, ose nuk përgjigjet fare. Ky simptom zakonisht nuk ka asnjë lidhje me shifrën ose me certifikatat. Prefiksi i rrugëtuar nga ofruesi dorëzohet si rrugë IP, dhe mbartja e tij përmes OpenVPN do të thotë të riprodhosh atë rrugë në dy nivele dhe të ruash adresën burimore në rrugën e kthimit. Nuk nevojitet ura lidhëse e WAN, dhe shtimi i adresës në një ndërfaqe nuk krijon rrugën e sipërme.

Prefiksi fillimisht duhet të rrugëtohet drejt jush

Pyesni ofruesin se si dorëzohet blloku. Një prefiks i rrugëtuar drejt adresës kryesore të serverit tuaj është diçka tjetër nga adresat që ofruesi pret t'i arrijë drejtpërdrejt në një segment WAN. Vetëm modeli i parë funksionon me dizajnin këtu.

Nëse ofruesi rrugëton 198.51.100.64/28 drejt serverit tuaj të hyrjes, paketat për atë interval mbërrijnë në server dhe ndalen atje, përveç nëse i përcillni. Nëse ofruesi përkundrazi ura-lidh intervalin në uplinkun tuaj, serveri duhet t'i përgjigjet ARP për të, që është një problem tjetër.

Testoni modelin e dorëzimit përpara se të prekni OpenVPN: nga jashtë, bëni ping një adrese në bllok dhe shikoni cila ndërfaqe e merr. Nëse nuk arrin asgjë, asnjë konfigurim tuneli nuk do të ndihmojë. Nëse adresa përgjigjet drejtpërdrejt në WAN, ofruesi po ura-lidh në vend që të rrugëtojë, dhe dizajni më poshtë nuk zbatohet.

Dy nivele rrugëtimi: rruga e kernelit dhe iroute

OpenVPN ka nevojë për prefiksin në dy vende. Kernelit duhet t'i dijë se prefiksi i përket pajisjes së tunelit, që paketat e përcjella të hyjnë në OpenVPN në vend të rrugës standarde. OpenVPN gjithashtu duhet të dijë se cili klient i autentikuar zotëron prefiksin, dhe ai është shënimi iroute në drejtorinë specifike për klientin.

Rruga në anën e serverit duket kështu, ndërsa prefiksi dhe maska duhet të përputhen me alokimin:

ip route add 198.51.100.64/28 dev tun0

Konfigurimi specifik për klientin cakton pronësinë. Vendoseni në skedarin CCD të quajtur sipas emrit të përbashkët të certifikatës së klientit, dhe konfirmoni se pikërisht ajo drejtori është ajo që serveri lexon vërtet:

iroute 198.51.100.64 255.255.255.240

Dokumentacioni i OpenVPN për rrjetet e rrugëtuara përshkruan të dy nivelet dhe pse janë të ndara. Një rrugë kernel pa iroute dërgon paketa në tunel pa pronar, dhe OpenVPN i hedh ato. Një iroute pa rrugën e kernelit i lë paketat në rrugën standarde të serverit. Të dy gabimet duken nga ana e klientit si një tunel i thyer.

Ku jeton adresa e shërbimit

Prefiksi i deleguar nuk është e njëjta gjë si adresat e vetë tunelit. Numëroni lidhjen nga hapësira private nëse dëshironi, dhe vendosni adresën publike të shërbimit aty ku shërbimi funksionon vërtet.

Në një klient Linux që e përfundon shërbimin lokalisht, mjafton një adresë e vetme hosti:

ip address add 198.51.100.70/32 dev lo

Nëse prefiksi rrugëtohet më tej drejt një hosti VM ose një LAN tjetër, konfiguroni në vend të kësaj atë rrugë të poshtme dhe rrugën e kthimit të saj. Caktimi i çdo adrese në bllok klientit VPN nuk është i nevojshëm dhe krijon konflikte më vonë.

Ruani burimin publik në rrugën e kthimit

Një përgjigje nga prefiksi i deleguar duhet të dalë përmes tunelit dhe të arrijë rrugën e ofruesit. Nëse hosti i largët e dërgon përmes ISP-së së vet, adresa burimore duket e falsifikuar, dhe ofruesi ose destinacioni e hedh atë. Zgjidhja është një rregull i bazuar në burim ose një tabelë rrugëtimi e dedikuar, jo një NAT më i gjerë. Pa të, shërbimi funksionon nga partneri i tunelit dhe dështon nga çdo vend tjetër.

Në serverin e hyrjes, një rregull i gjerë masquerade është fajtori i zakonshëm. Ai e rishkruan burimin publik në adresën kryesore të serverit, dhe klienti nuk e sheh kurrë atë të vërtetën:

iptables -t nat -S POSTROUTING

Kufizoni NAT vetëm te klientët privatë të VPN që kanë nevojë për të dhe lini prefiksin e deleguar të përkthyer. Pastaj konfirmoni se serveri e përcjell prefiksin fare, sepse një zinxhir përcjelljeje me refuzim standard e hedh atë në heshtje.

Verifikoni të dy drejtimet përpara se t'i besoni

Verifikimi është katër vëzhgime, jo një. Konfirmoni se rruga e ofruesit arrin, kernelit dërgon prefiksin në tunel, OpenVPN ia atribuon klientit të saktë, dhe përgjigja kthehet me burimin publik të paprekur. Çdo vëzhgim ka komandën e vet, kështu që një dështim tregon një shtresë dhe jo të gjithë dizajnin. Ekzekutojini në atë rend pas çdo ndryshimi konfigurimi.

Pyesni kernelin se cilën rrugë merr një adresë e deleguar, dhe vëzhgoni tunelin ndërsa një kërkesë është në ekzekutim:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrimi i rrugës së kundërt mund të anulojë një rrugë të saktë. Kontrolloni cilësimin efektiv në tunel dhe në uplink, dhe mbani mend se modaliteti i rreptë refuzon trafikun, burimi i të cilit nuk përputhet me ndërfaqen nga e cila mbërriti:

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

Së fundi, testoni rastin e dështimit. Ndaloni tunelin dhe konfirmoni se prefiksi publik nuk rrjedh përmes uplinkut të zakonshëm. Rikthimi i VPN duhet ta kthejë shërbimin pa zgjeruar cilat porta ekspozon hosti.