Reittipohjainen vs. käytäntöpohjainen sivustojen välinen VPN: mikä eroaa

Molemmat mallit suojaavat samaa liikennettä samalla IPsec-koneistolla, ja ne eroavat siinä, mikä päättää, mikä paketti tulee tunneliin. Käytäntöpohjaisessa yhteydessä neuvotellut liikenteen valitsimet tekevät sen työn; reittipohjaisessa sen tekee reitti, joka osoittaa tunneliliitäntään. Näiden sekoittaminen tuottaa tutun tukiketjun, jossa tunneli ilmoittaa olevansa pystyssä, mutta sovellus ei tavoita mitään. Ero on tärkein silloin, kun lisäät verkon, ajat reititysprotokollaa tai selvität polkua, joka poistuu hiljaa väärästä uloskäynnistä.

Kaksi tapaa päättää, mikä tulee tunneliin

Käytäntöpohjainen VPN rakentaa suojaustavan, joka vastaa lähde- ja kohdeprefiksejä, ja salaa sitten kaiken, mikä sopii. Vertaisparin on neuvoteltava yhteensopivat valitsimet, joten tehollinen laajuus päätyy molempien osapuolten ehdottaman leikkaukseksi. Mikään leikkauksen ulkopuolella ei ole suojattu, mitä reititystaulu sanoo tahansa.

Reittipohjainen VPN luo liitännän, joka edustaa tunnelia, ja antaa reititystaulun lähettää liikennettä siihen. IKE-taustaohjelma asentaa edelleen tilan ja liitäntäkohtaisen käytännön, ja se on se yksityiskohta, joka ohitetaan, kun päätetään, että reitit ovat korvanneet salauksen. Molemmat mallit salaavat IPsecillä; vain valintamekanismi eroaa.

Lue alla oleva vertailu joukkona vikakuvioita, ei pistetaulukkona, sillä kumpikaan sarake ei voita itsessään.

Käytäntöpohjainen: valitsin on sopimus

Valitsimista neuvotellaan, niitä ei vain määritetä. Ehdota toisella puolella 10.10.0.0/16 ja toisella 10.10.1.0/24, niin yhteys kattaa sen, mihin neuvottelu päätyi, kun taas jokainen muu isäntä jää sen ulkopuolelle.

Lue asennettu tila konfiguraatiotiedoston sijaan. Linux-vertaisparilla ytimen omat taulut ovat perustotuus, ja ne näyttävät, mikä selvisi neuvottelusta. Käytäntö, joka nimeää oikeat prefiksit ilman vastaavaa tilaa, tarkoittaa, että yhteys ei koskaan noussut. Tila yhdessä väärän prefiksin käytännön kanssa on päinvastainen ongelma, ja se tuottaa tunnelin, joka näyttää terveeltä, kun yksi aliverkko ei tavoita mitään.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Vertaa molempia tulosteita prefikseihin, joiden uskot olevan suojattuja. Tämä yksi vertailu ratkaisee useimmat raportit toimivasta tunnelista ja tavoittamattomasta palvelimesta. Se osoittaa myös, kumpaa vertaisparia muuttaa, koska eroavaisuus näkyy yleensä vain yhteen suuntaan.

Reittipohjainen: liitäntä on sopimus

XFRM-liitäntä antaa tunnelille nimen ja identiteetin, ja liikenne tavoittaa sen, koska reititystaulu niin sanoo. Useat etäprefiksit muuttuvat silloin reititysongelmaksi eikä valitsinongelmaksi, ja reititysprotokolla voi mainostaa niitä. Se on todellinen hyöty, ei salaus.

Liitäntä ei poista käytännön tarvetta. Taustaohjelma asentaa liitännän identiteettiin sidotut säännöt joka liitännälle, joten väärälle liitännälle saapuva paketti epäonnistuu silti. Lähdeosoite, jota vertaispari ei hyväksy, epäonnistuu myös, vaikka reitti olisi täydellinen. Reittipohjainen tarkoittaa, että reitti päättää sisääntulon, ei sitä, että käytäntö olisi kadonnut.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Seuraa liitännän laskureita, kun reitti on paikallaan. Reitti on olemassa, mutta laskurit pysyvät nollassa, mikä tarkoittaa, että mitään ei soviteta tunneliin, ja se viittaa yleensä puuttuvaan tilaan eikä puuttuvaan reittiin.

Missä kaksi mallia todella erkanevat

Verkon lisääminen on puhtain testi siitä, mikä malli sopii sinulle. Reittipohjainen malli lisää reitin ja laajentaa valitsinta enintään kerran, kun taas käytäntöpohjainen malli muokkaa prefiksipareja molemmilla vertaispareilla ja neuvottelee uudelleen. Kaksi vakaata aliverkkoa tekee muutoksesta triviaalin ja kaksikymmentä tekee siitä projektin.

Kumpikaan malli ei korvaa palomuuria, ja vertailut pysähtyvät yleensä ennen tätä kohtaa. Laaja valitsin tai laaja reitti päättää, mikä salataan, ei sitä, mikä on sallittua.

Myös MTU:n käyttäytyminen eroaa käytännössä. Kapselointi pienentää käytettävissä olevaa hyötykuormaa ja reittipohjainen liitäntä kantaa oman MTU:nsa, joten MSS:n kiinnittäminen molemmissa yhdyskäytävissä välttää mustan aukon oireen, jossa pienet vastaukset saapuvat ja suuret katoavat. Käytäntöpohjaiset tunnelit kohtaavat saman seinän toiselta puolelta, koska valitsin ei kerro paketin koosta mitään. Aseta kiinnitys tarkoituksella sen sijaan, että syyttäisit vertaisparia.

Siirtyminen menettämättä paluureittiä

Kirjaa olemassa olevat prefiksiparit ennen kuin muutat mitään, siirrä sitten yksi sovelluksen polku ja seuraa sitä päästä päähän. Tunneli, joka nousee, ei ole tunneli, joka välittää, ja ero näkyy vastauksen suunnassa.

Kun vertaisparit yhdistyvät mutta LAN-isännät eivät, tarkista paluureitti ja lähdeosoite, jota kaukoisäntä käyttää. Isäntä, jolla on kaksi liitäntää, voi vastata väärästä, eikä mikään valitsimen muutos korjaa sitä. Kaappaa liikenne molemmissa päissä ennen algoritmien muokkaamista.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Pidä työn aikana hallintapolku, joka ei riipu tunnelista. Palauttaminen on helpompaa, kun yhdyskäytävän oma pääsy ei kulje sen yhteyden päällä, jota selvität.