VPN med lokacijami ali oddaljeni dostop: kaj vsak poveže
Eno poveže prehode, drugo poveže naprave. Primerjajte izbirnike prometa s potmi, načrtujte naslavljanje in nato preizkusite posredovanje in politiko z resničnega gostitelja.
Obe rešitvi se imenujeta VPN in rešujeta različne probleme. Tunel med lokacijami poveže dva prehoda, tako da lahko vsak gostitelj za njima doseže dovoljene naslove na drugi strani, ne da bi karkoli namestil. Tunel oddaljenega dostopa poveže posamezne naprave v omrežje, po enega odjemalca naenkrat. Primerjava je pomembna, ker večina napak pri uvajanju nastane zaradi konfiguriranja ene rešitve ob pričakovanju vedenja druge, simptom pa je običajno potek časa pri storitvi, ki jo je tunel resnično dosegel.
Dve zasnovi, dve meji
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Nobena zasnova ne razširi domene oddajanja LAN. Naprave na oddaljeni strani se ne pojavijo na lokalnem seznamu odkrivanja in pričakovati to je prva predpostavka, ki se ji je treba odpovedati. Zasebna imena DNS, ki jih namerno objavljate, so bolj predvidljiva od katerega koli protokola odkrivanja in preživijo menjavo ponudnika.
Vzemite 10.10.0.0/24 na eni lokaciji in 10.20.0.0/24 na drugi. Prehod A potrebuje pot ali izbirnik prometa, ki pošlje predpono 10.20.0.0/24 v tunel, prehod B pa potrebuje njeno zrcalno sliko. Gostitelji na obeh straneh nato uporabljajo običajno povezljivost IP in nikoli ne izvejo, da tunel obstaja. Ta nevidnost je funkcija in zato so okvare videti kot običajne omrežne napake, ne kot napake tunela.
Na politiki in na poti zasnovano ni isti tunel
Pri uvajanju IPsec na podlagi politike pogajani izbirniki prometa natančno določajo, kateri pari vira in cilja so zaščiteni. Če se za enim prehodom pojavi novo podomrežje in ga noben izbirnik ne pokrije, tunel ostane aktiven, novo podomrežje pa se preprosto ne prenaša. Pri zasnovi na podlagi poti promet prevzame vmesnik in odloči usmerjevalna tabela, kar dodajanje predpone spremeni v spremembo usmerjanja in ne v ponovno pogajanje tunela.
StrongSwan neposredno prikaže oba pogleda in branje obeh skupaj je način, da ugotovite, kateri model ste dejansko uvedli.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'
Seznam izbirnikov, ki izpušča predpono, ki jo potrebujete, pojasni okvaro brez kakršnega koli zajemanja paketov, pot, ki kaže na napačen vmesnik, pa pojasni zrcalno okvaro na poti nazaj. Preberite oboje, preden karkoli znova pogajate, ker obnova ključa ne doda izbirnika, ki ga nikoli niste konfigurirali.
Načrtujte naslavljanje pred tunelom
Prekrivajoči se razponi so napaka v zasnovi, ki je s konfiguracijo ni mogoče popraviti. Če obe lokaciji uporabljata 192.168.1.0/24, ima gostitelj, ki potrebuje 192.168.1.50, dva kandidata in nobenega načina za izbiro. Tunel se bo overil, varnostne povezave se bodo vzpostavile, odločitev o usmerjanju pa bo vseeno napačna ali dvoumna.
Izberite eno od treh poštenih možnosti: preštevilčite eno lokacijo, prevedite prekrivajoči se razpon na prehodu, da vsaka stran vidi svojo predpono, ali se odpovejte neposrednemu usmerjanju za te gostitelje in storitev objavite drugače. Vsaka ima ceno in prva je običajno najcenejša v dvoletnem obdobju. Odločite se, preden tunel obstaja, ker se bo poznejša sprememba dotaknila vsake naprave s starim naslovom.
Tudi vprašanje MTU rešite zgodaj. Tunel zmanjša uporabno obremenitev in zasnova, ki se zanaša na razdrobljenost, se obnaša drugače od tiste, ki na prehodih določi MSS.
Posredovanje in politika stojita zunaj tunela
Prehod mora biti pripravljen posredovati pakete med vmesnikom tunela in vmesnikom LAN, obe smeri pa potrebujeta politiko, ki storitev dovoljuje. V Linuxu sta to dve ločeni nastavitvi, poleg tega pa pravila požarnega zidu, ki odločijo, ali je posredovani tok sploh dovoljen.
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
Prejemni gostitelj doda tretjo plast: njegov požarni zid mora še vedno sprejeti odjemalca iz oddaljenega podomrežja. Datotečni strežnik, ki dovoljuje le svoj lokalni /24, bo zavrnil posredovani promet z 10.20.0.7, ne glede na to, kako zdrav je videti tunel, in to zavrnitev je lahko brati kot okvaro usmerjanja.
Preizkusite z gostitelja, ne s prehoda
Ping, ki ga pošlje prehod sam, lahko sledi drugemu izvornemu naslovu in drugi politiki kot posredovani uporabniški promet. Zato je šibek preizkus in včasih zavajajoč: uspe, ko aplikacija ne uspe, ali ne uspe, ko aplikacija deluje.
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
Uporabite resničnega gostitelja, resnični izvorni naslov in resnični protokol, ki ga aplikacija uporablja. Nato ločeno preberite povratno pot, ker delujoča smer naprej brez povratne poti povzroči potek časa, ki je videti enako kot blokirana storitev.
Zasnovo izberite glede na vprašanje, na katero odgovarjate: povezujete omrežja ali sprejemate naprave? Vse ostalo, tudi to, katerega ponudnika konfigurirate, izhaja iz tega odgovora.