VPN starp vietnēm vai attālināta piekļuve: ko katrs savieno

Abi risinājumi tiek saukti par VPN, un tie risina dažādas problēmas. Tunelis starp vietnēm savieno divas vārtejas, tāpēc katrs aiz tām esošais resursdators var sasniegt atļautās adreses otrā pusē, neko neinstalējot. Attālinātās piekļuves tunelis savieno atsevišķas ierīces ar tīklu, pa vienam klientam vienlaikus. Salīdzinājums ir svarīgs, jo lielākā daļa izvietošanas kļūdu rodas, konfigurējot vienu risinājumu un gaidot otra uzvedību, un simptoms parasti ir taimauts pakalpojumā, kuru tunelis patiešām sasniedza.

Divi risinājumi, divas robežas

Neviens risinājums nepaplašina LAN apraides domēnu. Ierīces otrā pusē neparādās lokālajā atklāšanas sarakstā, un to gaidīt ir pirmais pieņēmums, no kura jāatsakās. Privātie DNS nosaukumi, ko apzināti publicējat, ir paredzamāki par jebkuru atklāšanas protokolu, un tie pārdzīvo piegādātāja maiņu.

Ņemiet 10.10.0.0/24 vienā vietnē un 10.20.0.0/24 otrā. Vārtejai A vajag maršrutu vai trafika selektoru, kas nosūta prefiksu 10.20.0.0/24 tunelī, un vārtejai B vajag tā spoguļattēlu. Pēc tam abu pušu resursdatori izmanto parastu IP savienojumu un nekad neuzzina, ka tunelis pastāv. Šī neredzamība ir funkcija, un tāpēc kļūmes izskatās kā parastas tīkla kļūdas, nevis tuneļa kļūdas.

Uz politiku balstīts un uz maršrutu balstīts nav viens un tas pats tunelis

Uz politiku balstītā IPsec izvietošanā saskaņotie trafika selektori precīzi nosaka, kuri avota un galamērķa pāri ir aizsargāti. Ja aiz vienas vārtejas parādās jauns apakštīkls un neviens selektors to neaptver, tunelis paliek aktīvs, un jaunais apakštīkls vienkārši netiek pārsūtīts. Uz maršrutu balstītā risinājumā trafiku saņem interfeiss, un lēmumu pieņem maršrutēšanas tabula, kas prefiksa pievienošanu padara par maršruta izmaiņu, nevis atkārtotām tuneļa sarunām.

StrongSwan tieši parāda abus skatus, un to lasīšana kopā ir veids, kā noskaidrot, kuru modeli jūs patiešām izvietojāt.

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

Selektoru saraksts, kurā trūkst jums svarīgā prefiksa, izskaidro kļūmi bez jebkādas pakešu uztveršanas, un maršruts uz nepareizo interfeisu izskaidro spoguļkļūmi atceļā. Izlasiet abus pirms kaut ko atkārtoti sarunāt, jo atslēgas atjaunošana nepievienos selektoru, kuru nekad neesat konfigurējis.

Izplānojiet adresāciju pirms tuneļa

Pārklājošie diapazoni ir projektēšanas kļūda, ko nevar izlabot ar konfigurāciju. Ja abas vietnes izmanto 192.168.1.0/24, resursdatoram, kuram vajag 192.168.1.50, ir divi kandidāti un nav veida, kā izvēlēties. Tunelis autentificēsies, drošības asociācijas tiks izveidotas, un maršrutēšanas lēmums joprojām būs nepareizs vai neviennozīmīgs.

Izvēlieties vienu no trim godīgiem variantiem: pārnumurēt vienu vietni, pārtulkot pārklājošo diapazonu vārtejā, lai katra puse redzētu atšķirīgu prefiksu, vai atteikties no tiešas maršrutēšanas šiem resursdatoriem un publicēt pakalpojumu citādi. Katram ir sava cena, un pirmais parasti ir lētākais divu gadu horizontā. Izlemiet pirms tuneļa pastāvēšanas, jo pēc tam izmaiņas skars katru ierīci ar veco adresi.

Arī MTU jautājumu atrisiniet agri. Tunelis samazina izmantojamo kravu, un uz fragmentāciju balstīts risinājums uzvedas citādi nekā tāds, kas fiksē MSS vārtejās.

Pārsūtīšana un politika atrodas ārpus tuneļa

Vārtejai jābūt gatavai pārsūtīt paketes starp tuneļa interfeisu un LAN interfeisu, un abiem virzieniem vajag politiku, kas atļauj pakalpojumu. Linux tas ir divi atsevišķi iestatījumi, plus ugunsmūra noteikumi, kas izlemj, vai pārsūtītā plūsma vispār ir atļauta.

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

Saņēmējs resursdators pievieno trešo slāni: tā paša ugunsmūrim joprojām jāpieņem klients no attālinātā apakštīkla. Failu serveris, kas atļauj tikai savu lokālo /24, noraidīs pārsūtīto trafiku no 10.20.0.7, lai cik vesels tunelis izskatītos, un šo noraidījumu ir viegli nolasīt kā maršrutēšanas kļūmi.

Pārbaudiet no resursdatora, nevis no vārtejas

Vārtejas pašas sūtītais ping var sekot citai avota adresei un citai politikai nekā pārsūtītais lietotāja trafiks. Tas padara to par vāju testu un dažkārt maldinošu: tas izdodas, kamēr lietojumprogramma neizdodas, vai neizdodas, kamēr lietojumprogramma darbojas.

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

Izmantojiet reālu resursdatoru, reālu avota adresi un reālo protokolu, ko izmanto lietojumprogramma. Pēc tam atsevišķi izlasiet atgriešanās ceļu, jo strādājošs virziens uz priekšu bez atgriešanās maršruta rada taimautu, kas izskatās identiski bloķētam pakalpojumam.

Izvēlieties risinājumu pēc jautājuma, uz kuru atbildat: vai jūs savienojat tīklus vai uzņemat ierīces? Viss pārējais, tostarp tas, kuru piegādātāju konfigurējat, izriet no šīs atbildes.