VPN tarp svetainių arba nuotolinė prieiga: ką kiekvienas sujungia

Abu sprendimai vadinami VPN ir sprendžia skirtingas problemas. Tunelis tarp svetainių sujungia du šliuzus, todėl kiekvienas už jų esantis pagrindinis kompiuteris gali pasiekti leidžiamus adresus kitoje pusėje nieko neįdiegęs. Nuotolinės prieigos tunelis sujungia atskirus įrenginius su tinklu, po vieną klientą vienu metu. Palyginimas svarbus, nes dauguma diegimo klaidų kyla konfigūruojant vieną sprendimą ir tikintis kito elgsenos, o simptomas paprastai yra skirtasis laikas paslaugoje, kurią tunelis tikrai pasiekė.

Du sprendimai, dvi ribos

Nė vienas sprendimas neišplečia LAN transliacijos domeno. Įrenginiai kitoje pusėje nepasirodo vietiniame aptikimo sąraše, ir to tikėtis yra pirmoji prielaida, kurios reikia atsisakyti. Privatūs DNS vardai, kuriuos sąmoningai skelbiate, yra labiau nuspėjami nei bet kuris aptikimo protokolas ir išlieka pasikeitus tiekėjui.

Paimkite 10.10.0.0/24 vienoje svetainėje ir 10.20.0.0/24 kitoje. Šliuzui A reikia maršruto arba srauto selektoriaus, kuris siunčia priešdėlį 10.20.0.0/24 į tunelį, o šliuzui B reikia jo veidrodinio atspindžio. Tada abiejų pusių pagrindiniai kompiuteriai naudoja įprastą IP ryšį ir niekada nesužino, kad tunelis egzistuoja. Tas nematomumas yra funkcija, ir todėl gedimai atrodo kaip įprastos tinklo klaidos, o ne tunelio klaidos.

Politika pagrįstas ir maršrutu pagrįstas nėra tas pats tunelis

Politika pagrįstame IPsec diegime suderinti srauto selektoriai tiksliai apibrėžia, kurios šaltinio ir paskirties poros yra apsaugotos. Jei už vieno šliuzo atsiranda naujas potinklis ir joks selektorius jo neapima, tunelis lieka veikti, o naujas potinklis tiesiog neperduodamas. Maršrutu pagrįstame sprendime srautą priima sąsaja, o sprendžia maršrutų lentelė, todėl priešdėlio pridėjimas tampa maršruto pakeitimu, o ne naujomis tunelio derybomis.

StrongSwan tiesiogiai rodo abu vaizdus, ir jų skaitymas kartu yra būdas išsiaiškinti, kurį modelį iš tikrųjų įdiegėte.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Selektorių sąrašas, kuriame trūksta jums svarbaus priešdėlio, paaiškina gedimą be jokio paketų fiksavimo, o maršrutas į netinkamą sąsają paaiškina veidrodinį gedimą grįžtant. Perskaitykite abu prieš ką nors iš naujo derėdamiesi, nes rakto atnaujinimas nepridės selektoriaus, kurio niekada nesukonfigūravote.

Suplanuokite adresavimą prieš tunelį

Persidengiantys diapazonai yra projektavimo klaida, kurios negalima ištaisyti konfigūracija. Jei abi svetainės naudoja 192.168.1.0/24, pagrindinis kompiuteris, kuriam reikia 192.168.1.50, turi du kandidatus ir jokio būdo pasirinkti. Tunelis autentifikuosis, saugos asociacijos bus užmegztos, o maršrutizavimo sprendimas vis tiek bus klaidingas arba dviprasmiškas.

Pasirinkite vieną iš trijų sąžiningų variantų: pernumeruoti vieną svetainę, išversti persidengiantį diapazoną šliuze, kad kiekviena pusė matytų atskirą priešdėlį, arba atsisakyti tiesioginio maršrutizavimo tiems kompiuteriams ir paskelbti paslaugą kitaip. Kiekvienas turi kainą, o pirmasis paprastai yra pigiausias dvejų metų horizonte. Nuspręskite prieš atsirandant tuneliui, nes vėliau pakeitimas palies kiekvieną įrenginį, turintį seną adresą.

MTU klausimą taip pat išspręskite anksti. Tunelis sumažina naudingąją apkrovą, o fragmentacija pagrįstas sprendimas elgiasi kitaip nei tas, kuris fiksuoja MSS šliuzuose.

Perdavimas ir politika yra už tunelio ribų

Šliuzas turi būti pasirengęs perduoti paketus tarp tunelio sąsajos ir LAN sąsajos, o abiem kryptims reikia politikos, kuri leidžia paslaugą. Linux sistemoje tai du atskiri nustatymai, be to, ugniasienės taisyklės, kurios nusprendžia, ar perduodamas srautas apskritai leidžiamas.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Priimantis pagrindinis kompiuteris prideda trečią sluoksnį: jo paties ugniasienė vis tiek turi priimti klientą iš nuotolinio potinklio. Failų serveris, leidžiantis tik savo vietinį /24, atmes perduodamą srautą iš 10.20.0.7, kad ir kaip sveikai atrodytų tunelis, ir tą atmetimą lengva perskaityti kaip maršrutizavimo gedimą.

Testuokite iš pagrindinio kompiuterio, o ne iš šliuzo

Šliuzo paties siunčiamas ping gali naudoti kitą šaltinio adresą ir kitą politiką nei perduodamas vartotojo srautas. Todėl tai silpnas testas, o kartais ir klaidinantis: jis pavyksta, kai programa nepavyksta, arba nepavyksta, kai programa veikia.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Naudokite tikrą pagrindinį kompiuterį, tikrą šaltinio adresą ir tikrą protokolą, kurį naudoja programa. Tada atskirai perskaitykite grįžimo kelią, nes veikianti ėjimo kryptis be grįžimo maršruto sukuria skirtąjį laiką, kuris atrodo identiškai kaip užblokuota paslauga.

Pasirinkite sprendimą pagal klausimą, į kurį atsakote: ar sujungiate tinklus, ar priimate įrenginius? Visa kita, įskaitant tai, kurį tiekėją konfigūruojate, kyla iš to atsakymo.