Vzdialení používatelia sa cez VPN koncentrátor nedostanú na druhú lokalitu

Vzdialený používateľ sa pripojí ku koncentrátoru, dostane sa na súborový server v jeho vlastnej LAN a všetko vyzerá zdravo. Potom otvorí zdieľanie na 10.20.0.50 v ústredí, kam sa koncentrátor dostane cez samostatný tunel lokalita-lokalita, a požiadavka vyprší. Obidva tunely sú aktívne a obidva počítadlá rastú, takže žiadny tunel nie je pokazený. Prechod cez koncentrátor sú tri rozhodnutia smerovania na troch zariadeniach, a tunel prenáša len tie prefixy, pre ktoré bol postavený. Tu je poradie, v ktorom to kontrolujem, a príkaz, ktorý ukazuje, či každý krok platí.

Tranzit si vyžaduje tri vyhľadania, nie jeden tunel

Každé zariadenie robí vlastnú zhodu najdlhšieho prefixu a zabudne ju. Laptop musí posielať 10.20.0.50 do tunela, nie do svojho lokálneho smerovača. Koncentrátor musí prevziať paket, ktorý prišiel na rozhraní vzdialeného prístupu, a odovzdať ho rozhraniu lokalita-lokalita. Ústredie musí poslať odpoveď na adresu používateľa späť cez tunel. Ktorékoľvek z tých troch zlyhaní vyzerá v prehliadači rovnako: ticho.

Preto testovanie každého tunela zvlášť dokazuje tak málo. Ping na adresu LAN koncentrátora precvičuje prvé rozhodnutie a ping na koncentrátor z ústredia tretie. Paket, ktorý zlyhá, má ako zdroj pool používateľov a ako cieľ druhú lokalitu, preto si najprv zapíšte tie prefixy. Tu je pool 10.80.0.0/24, LAN koncentrátora je 10.10.0.0/24 a ústredie je 10.20.0.0/24.

Vtlačte vzdialený prefix vzdialenému klientovi

Na serveri vzdialeného prístupu OpenVPN klient sa učí trasy pri pripojení. Bez push klient s rozdeleným tunelom pošle 10.20.0.50 svojej vlastnej bráne a paket sa nikdy nedostane do tunela.

push "route 10.20.0.0 255.255.255.0"

Vtlačená trasa sa uplatní, keď sa klient pripojí, takže používateľ, ktorý zostane online, nič nevidí, kým sa nepripojí znova. Overte na klientovi: ip route get 10.20.0.50 v Linuxe, route print vo Windows. Výstup by mal uviesť rozhranie tunela.

push koncentrátoru nepomáha. Je to správa pre klienta, nie trasa na serveri a nie povolenie preposielať, takže koncentrátor s dokonalým riadkom push stále zahodí tok o jeden skok ďalej. To je obvyklý dôvod, prečo ľudia usúdia, že push zlyhal.

Dajte koncentrátoru skutočnú výstupnú trasu

Koncentrátor potrebuje vlastný ďalší skok pre prefix ústredia. Na smerovanom tuneli je to bežná trasa cez rozhranie lokalita-lokalita a jeden príkaz ukáže aj zvolenú trasu, aj zvolený zdroj:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Tam, kde je rameno lokalita-lokalita samo OpenVPN, trasa môže žiť v tej konfigurácii s adresou tunela partnera ako bránou: route 10.20.0.0 255.255.255.0 172.30.0.2. Brána nie je voliteľná. Ak ju vynecháte, ďalší skok padne na implementačnú predvolenú hodnotu, ktorá sa líši medzi klientom s jedným vzdialeným bodom a koncentrátorom s viacerými partnermi.

IPsec založený na politikách je iný: jadro koncentrátora pošle paket svojej bežnej LAN bráne a politika ho zachytí na výstupe, takže trasa tunela buď nič nerobí, alebo vedie prevádzku popri politike. Sledujte zdroj v príkaze vyššie, pretože 10.10.0.1 namiesto adresy poolu znamená, že jadro zvolilo adresu, ktorú vzdialená strana odmietne. Ani iroute nie je odpoveď; hovorí serveru, ktorý klient vlastní podsiete za vlastným tunelom, nie kam posielať prevádzku pre tretiu lokalitu.

Rozšírte vzdialenú stranu na pool používateľov

Ústredie už pokrýva LAN koncentrátora, 10.10.0.0/24. Pool používateľov je druhý prefix a musí byť aj v selektoroch, inak žiadna politika nepokrýva odpoveď adresovanú 10.80.0.25. Každý partner vymenúva ten istý pár množín prefixov zo svojej strany:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts jedného zariadenia je remote_ts druhého. Skopírujte blok koncentrátora do ústredia a pár sa obráti, takže podradená SA nikdy nevstane.

Staršia syntax ipsec.conf používa leftsubnet oddelený čiarkami. Bežiaca bezpečnostná asociácia si drží selektory, o ktorých vyjednala, preto po úprave tunel znovu zaveste. Selektor zmenený o 10:00 a testovaný proti SA, ktorá vstala o 09:40, stále zlyháva, hoci konfiguračný súbor celý čas vyzerá správne.

Potom skontrolujte posledný skok. ip route get 10.80.0.25 na vzdialenom konci by mal ukazovať do tunela. Ak služba používa LAN smerovač ako svoju predvolenú bránu, ten smerovač potrebuje aj spiatočnú trasu, inak odpoveď tam zomrie. Spustenie tcpdump -ni eth1 host 10.80.0.25 na tom segmente ukáže, či odpoveď vôbec opustila koncový bod.

Povoľte tok na koncentrátore

Preposielanie musí byť zapnuté a cesta povolená. Obmedzte pravidlá na dva prefixy namiesto prijímania všetkého medzi rozhraniami.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Filtrovanie spätnej cesty je tiché zlyhanie vedľa: keď sú obe ramená na rôznych rozhraniach, rp_filter=1 môže zahodiť odpoveď, kým počítadlo povoľujúceho pravidla sa vôbec nepohne. Porovnajte iptables -vnL FORWARD pred pokusom a po ňom. Pravidlo, ktoré nikdy nerastie, nie je dosiahnuté, preto sa pozrite o vrstvu nižšie, namiesto prepisovania.

Ak tranzit potrebuje len jedna skupina, umiestnite trasu do súboru pre jednotlivého klienta v client-config-dir namiesto rozširovania globálneho push. Source NAT na koncentrátore tiež odstraňuje potrebu spiatočnej trasy na vzdialenej strane, ale skrýva adresu používateľa, takže záznamy vzdialenej lokality a pravidlá založené na adresách prestávajú rozlišovať používateľov.

Overte z klienta a potom vráťte v opačnom poradí

Testujte TCP port, nie len ICMP, pretože ping môže prejsť, kým služba zostáva zablokovaná. nc -vz 10.20.0.50 445 a traceroute -n 10.20.0.50 z klienta ukazujú, či je druhý skok adresou tunela koncentrátora. Na koncentrátore tcpdump -ni tun0 host 10.20.0.50 a rovnaký filter na rozhraní lokalita-lokalita: požiadavka na oboch bez odpovede na žiadnom presúva problém na vzdialenú stranu.

Potom otestujte niečo, čo musí zostať zablokované. Ak odpovie aj hostiteľ, ku ktorému sa pool nikdy nemá dostať, otvorili ste viac než tranzit a pravidlá by ste mali zúžiť. Koncentrátor, ktorý preposiela všetko každej vetve, prejde prvým testom a zlyhá v druhom.

Vedte zoznam vrátenia, pretože zmenili sa štyri objekty a tri sa ľahko zabudnú: vtlačená trasa, trasa koncentrátora, selektory a pravidlá firewallu. Zrušte ich v opačnom poradí, znovu zaveste SA a nechajte jedného používateľa pripojiť sa znova. Čiastočné vrátenie necháva trasu ukazujúcu na tunel, ktorý už nesedí, a to sa číta ťažšie než pôvodné ticho. Príručka OpenVPN 2.6 dokumentuje push, route a iroute pre vašu verziu.