Saitidevaheline versus kaugjuurdepääsu-VPN: mida kumb ühendab

Mõlemat lahendust nimetatakse VPN-iks ja need lahendavad erinevaid probleeme. Saitidevaheline tunnel ühendab kaks lüüsi, nii et iga host nende taga pääseb teisel poolel lubatud aadressidele ilma midagi paigaldamata. Kaugjuurdepääsu tunnel ühendab üksikud seadmed võrku, üks klient korraga. Võrdlus on oluline, sest enamik juurutamisvigu tekib sellest, et seadistatakse üht lahendust, oodates teise käitumist, ja sümptomiks on tavaliselt aegumine teenuses, kuhu tunnel tegelikult jõudis.

Kaks lahendust, kaks piiri

Kumbki lahendus ei laienda LAN-i saatedomeeni. Teisel poolel olevad seadmed ei ilmu kohalikku avastusnimekirja ja selle ootamine on esimene eeldus, millest tuleb loobuda. Privaatsed DNS-nimed, mille teadlikult avaldate, on prognoositavamad kui ükskõik milline avastusprotokoll ja need peavad vastu tarnija vahetusele.

Võtke ühes saidis 10.10.0.0/24 ja teises 10.20.0.0/24. Lüüs A vajab marsruuti või liiklusvalijat, mis saadab prefiksi 10.20.0.0/24 tunnelisse, ja lüüs B vajab selle peegelpilti. Seejärel kasutavad mõlema poole hostid tavalist IP-ühendust ega saa kunagi teada, et tunnel on olemas. See nähtamatus on funktsioon, ja seepärast näevad tõrked välja nagu tavalised võrguvead, mitte tunnelivead.

Poliitikal põhinev ja marsruudil põhinev ei ole sama tunnel

Poliitikal põhinevas IPsec-i juurutuses määravad kokku lepitud liiklusvalijad täpselt, millised lähte- ja sihtpaarid on kaitstud. Kui ühe lüüsi taga ilmub uus alamvõrk ja ükski valija seda ei kata, jääb tunnel püsti ja uus alamvõrk lihtsalt ei kandu. Marsruudil põhinevas lahenduses võtab liidese liikluse vastu ja otsustab marsruutimistabel, mis teeb prefiksi lisamisest marsruudimuudatuse, mitte tunneli uuesti läbirääkimise.

StrongSwan näitab mõlemat vaadet otse ja nende koos lugemine on viis, kuidas teada saada, millise mudeli te tegelikult juurutasite.

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

Valijate nimekiri, millest puudub teile oluline prefiks, selgitab tõrget ilma igasuguse paketipüügi, ja vale liidese poole osutav marsruut selgitab peegeltõrget tagasiteel. Lugege mõlemat enne, kui midagi uuesti läbi räägite, sest võtmeuuendus ei lisa valijat, mida te kunagi ei seadistanud.

Planeerige adresseerimine enne tunnelit

Kattuvad vahemikud on projekteerimisviga, mida seadistusega parandada ei saa. Kui mõlemad saidid kasutavad 192.168.1.0/24, siis hostil, kes vajab 192.168.1.50, on kaks kandidaati ja mitte mingit võimalust valida. Tunnel autendib end, turbeseosed luuakse ja marsruutimisotsus on ikkagi vale või mitmetähenduslik.

Valige üks kolmest ausast võimalusest: nummerdage üks sait ümber, tõlkige kattuv vahemik lüüsis, et kumbki pool näeks erinevat prefiksit, või loobuge nende hostide jaoks otsesest marsruutimisest ja avaldage teenus muul viisil. Igal on hind ja esimene on tavaliselt kaheaastase horisondi jooksul odavaim. Otsustage enne, kui tunnel olemas on, sest hiljem puudutab muudatus iga seadet, millel on vana aadress.

Lahendage ka MTU küsimus varakult. Tunnel vähendab kasulikku kandevõimet ja fragmenteerimisele toetuv lahendus käitub teisiti kui see, mis kinnistab MSS-i lüüsides.

Edasisaatmine ja poliitika asuvad väljaspool tunnelit

Lüüs peab olema valmis edasi saatma pakette tunnelliidese ja LAN-liidese vahel ning mõlemad suunad vajavad poliitikat, mis lubab teenust. Linuxis on need kaks eraldi seadet, lisaks tulemüürireeglid, mis otsustavad, kas edasisaadetav voog on üldse lubatud.

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

Vastuvõttev host lisab kolmanda kihi: tema enda tulemüür peab ikkagi vastu võtma kliendi kaugest alamvõrgust. Failiserver, mis lubab ainult oma kohalikku /24, lükkab tagasi edasisaadetud liikluse aadressilt 10.20.0.7, ükskõik kui terve tunnel välja näeb, ja seda tagasilükkamist on lihtne marsruudiveaks lugeda.

Testige hostist, mitte lüüsist

Lüüsi enda saadetud ping võib järgida teistsugust lähteaadressi ja teistsugust poliitikat kui edasisaadetav kasutajaliiklus. See teeb sellest nõrga testi ja mõnikord eksitava: see õnnestub, kui rakendus ebaõnnestub, või ebaõnnestub, kui rakendus töötab.

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

Kasutage päris hosti, päris lähteaadressi ja päris protokolli, mida rakendus kasutab. Seejärel lugege vastuseteed eraldi, sest töötav edasisuund ilma tagasiteeta annab aegumise, mis näeb välja täpselt nagu blokeeritud teenus.

Valige lahendus küsimuse järgi, millele vastate: kas ühendate võrke või võtate vastu seadmeid? Kõik muu, sealhulgas see, millist tarnijat seadistate, tuleneb sellest vastusest.