Sivustojen välinen VPN vastaan etäkäyttö: mitä kumpikin yhdistää

Molempia ratkaisuja kutsutaan VPN:ksi ja ne ratkaisevat eri ongelmia. Sivustojen välinen tunneli yhdistää kaksi yhdyskäytävää, joten jokainen niiden takana oleva isäntä voi saavuttaa toisella puolella sallitut osoitteet asentamatta mitään. Etäkäyttötunneli yhdistää yksittäisiä laitteita verkkoon, yhden asiakkaan kerrallaan. Vertailu on tärkeä, koska useimmat käyttöönoton virheet syntyvät siitä, että määritetään toista ja odotetaan toisen käyttäytymistä, ja oireena on yleensä aikakatkaisu palvelussa, johon tunneli todella pääsi.

Kaksi ratkaisua, kaksi rajaa

Kumpikaan ratkaisu ei laajenna LAN-lähetysverkkotunnusta. Toisella puolella olevat laitteet eivät näy paikallisessa etsintäluettelossa, ja sen odottaminen on ensimmäinen oletus, josta on luovuttava. Yksityiset DNS-nimet, jotka julkaiset tarkoituksella, ovat ennustettavampia kuin mikään etsintäprotokolla, ja ne kestävät toimittajan vaihtumisen.

Ota 10.10.0.0/24 toisella sivustolla ja 10.20.0.0/24 toisella. Yhdyskäytävä A tarvitsee reitin tai liikenteen valitsimen, joka lähettää etuliitteen 10.20.0.0/24 tunneliin, ja yhdyskäytävä B tarvitsee sen peilikuvan. Tämän jälkeen molempien puolten isännät käyttävät tavallista IP-yhteyttä eivätkä koskaan saa tietää, että tunneli on olemassa. Näkymättömyys on ominaisuus, ja siksi viat näyttävät tavallisilta verkkovirheiltä eikä tunnelivirheiltä.

Käytäntöpohjainen ja reittipohjainen eivät ole sama tunneli

Käytäntöpohjaisessa IPsec-käyttöönotossa neuvotellut liikenteen valitsimet määrittävät tarkasti, mitkä lähde- ja kohdeparit on suojattu. Jos yhdyskäytävän taakse ilmestyy uusi aliverkko eikä mikään valitsin kata sitä, tunneli pysyy pystyssä ja uutta aliverkkoa ei yksinkertaisesti välitetä. Reittipohjaisessa ratkaisussa rajapinta vastaanottaa liikenteen ja reititystaulu päättää, mikä tekee etuliitteen lisäämisestä reittimuutoksen eikä tunnelin uudelleenneuvottelun.

StrongSwan näyttää molemmat näkymät suoraan, ja niiden lukeminen yhdessä on tapa selvittää, minkä mallin oikeastaan otit käyttöön.

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

Valitsinluettelo, josta puuttuu sinulle tärkeä etuliite, selittää vian ilman mitään paketinkaappausta, ja väärään rajapintaan osoittava reitti selittää peilikuvan vian paluumatkalla. Lue molemmat ennen kuin neuvottelet mitään uudelleen, sillä avaimen uusinta ei lisää valitsinta, jota et koskaan määrittänyt.

Suunnittele osoitteistus ennen tunnelia

Päällekkäiset alueet ovat suunnitteluvirhe, jota ei voi korjata määrityksillä. Jos molemmat sivustot käyttävät 192.168.1.0/24:ää, isännällä, joka tarvitsee 192.168.1.50:n, on kaksi ehdokasta eikä mitään tapaa valita. Tunneli todentuu, tietoturvayhteydet muodostuvat ja reitityspäätös on silti väärä tai epäselvä.

Valitse yksi kolmesta rehellisestä vaihtoehdosta: numeroi toinen sivusto uudelleen, käännä päällekkäinen alue yhdyskäytävässä niin että kumpikin puoli näkee eri etuliitteen, tai luovu suorasta reitityksestä näille isännille ja julkaise palvelu toisella tavalla. Jokaisella on hintansa, ja ensimmäinen on yleensä halvin kahden vuoden aikajänteellä. Päätä ennen kuin tunneli on olemassa, sillä jälkeenpäin muutos koskettaa jokaista laitetta, jolla on vanha osoite.

Ratkaise myös MTU-kysymys aikaisin. Tunneli pienentää käyttökelpoista hyötykuormaa, ja pirstoutumiseen nojaava ratkaisu käyttäytyy eri tavalla kuin sellainen, joka kiinnittää MSS:n yhdyskäytävissä.

Välitys ja käytäntö ovat tunnelin ulkopuolella

Yhdyskäytävän on oltava halukas välittämään paketteja tunnelirajapinnan ja LAN-rajapinnan välillä, ja molemmat suunnat tarvitsevat käytännön, joka sallii palvelun. Linuxissa nämä ovat kaksi erillistä asetusta, lisäksi palomuurisäännöt, jotka päättävät, sallitaanko välitetty virta ylipäätään.

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

Vastaanottava isäntä lisää kolmannen kerroksen: sen oma palomuuri joutuu yhä hyväksymään asiakkaan etäisestä aliverkosta. Tiedostopalvelin, joka sallii vain paikallisen /24:nsä, hylkää välitetyn liikenteen osoitteesta 10.20.0.7, niin terveeltä kuin tunneli näyttää, ja se hylkäys on helppo lukea reititysvirheeksi.

Testaa isännästä, älä yhdyskäytävästä

Yhdyskäytävän itsensä lähettämä ping voi noudattaa eri lähdeosoitetta ja eri käytäntöä kuin välitetty käyttäjäliikenne. Se tekee siitä heikon testin ja toisinaan harhaanjohtavan: se onnistuu, kun sovellus epäonnistuu, tai epäonnistuu, kun sovellus toimii.

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

Käytä oikeaa isäntää, oikeaa lähdeosoitetta ja oikeaa protokollaa, jota sovellus käyttää. Lue sitten paluureitti erikseen, sillä toimiva menosuunta ilman paluureittiä tuottaa aikakatkaisun, joka näyttää identtiseltä estetyn palvelun kanssa.

Valitse ratkaisu sen kysymyksen mukaan, johon vastaat: yhdistätkö verkkoja vai otatko vastaan laitteita? Kaikki muu, mukaan lukien se, mitä toimittajaa määrität, seuraa siitä vastauksesta.