Näin suunnittelet VPN-asiakkaiden osoitepoolin, joka sopii

Aloita VPN-palvelimen poolikentästä, älä laskentataulukosta. Se, mitä siihen kirjoitat, tulee sisäiseksi osoiteavaruudeksi jokaiselle asiakkaalle, joka yhdistää myöhemmin, ja sen on oltava olemassa yhdessä sen LANin kanssa, johon nämä asiakkaat pääsevät, sen takana olevien reititettyjen sivustojen ja minkä tahansa osoitteen kanssa, joka asiakkaalla on jo kotonaan. Yhdistä yksi asiakas heti, kun pooli on tallennettu, koska tuo ensimmäinen yhteys kertoo, toimiiko arvo käytännössä. Siitä eteenpäin kiertue etenee ulospäin: osoite, jonka asiakas sai, polku, jonka vastaus kulkee, ja muistiinpano, jonka jätät jälkeesi.

Aloita poolikentästä, ennen kuin yksikään asiakas yhdistää

Jokainen tuote esittää tämän eri tavalla, joten etsi objekti, joka todella jakaa osoitteita. OpenVPN:ssä on palvelinpuolen poolikäsky, joka jakaa seuraavan vapaan osoitteen, IKEv2-yhdyskäytävässä on vertaiskonfiguraatioon sidottu pooliosio, ja WireGuardissa ei ole kumpaakaan, koska jokainen vertaislaite kantaa oman osoitteensa omassa konfiguraatiotiedostossaan. Poolikäsky ja vertaiskohtainen osoite eivät ole vaihdettavissa, ja väärän muokkaaminen tuhlaa kiertueen loppuosan.

Kun kenttä on hallussasi, luettele alueet, jotka ovat jo olemassa: toimiston LAN, jokainen reititetty sivusto, pilven VPC ja mikä tahansa muu pooli, joka on vielä käytössä. Päällekkäisyys ratkaistaan etuliitearitmetiikalla, ei sillä, näyttävätkö isäntänumerot tutuilta, joten vertaa koostetta kuhunkin näistä alueista. Kaksi aluetta, jotka molemmat näyttävät 10.x:ltä, ovat vaarattomia, kun niiden koosteet eivät leikkaa, ja tukitapaus, kun leikkaavat.

Päätä sitten, onko osoite sen funktio, kuka yhdistää, vai sen, milloin he yhdistävät. Dynaaminen osoitus jakaa sen, mikä on vapaana, kun taas identiteettikohtainen osoitus sitoo kiinteän osoitteen valtuustietoihin. Kirjoita valinta muistiin, koska se muuttaa sitä, miltä uudelleenyhdistämisen pitäisi myöhemmin näyttää.

Lue osoite, jonka asiakas todella sai

Yhdistä yksi asiakas ja lue, mitä tunneli raportoi, älä sitä, mitä pooli lupasi. Asiakas näyttää sisäisen osoitteensa yhteyden tilassa, ja Linuxissa rajapinta kantaa sen suoraan.

Vertaa tuota osoitetta tallennettuun alueeseen. Jos se on alueen ulkopuolella, katsot eri osoituspolkua kuin sitä, jota muokkasit. Tarkista myös etuliitteen pituus, koska asiakkaalla, jolla on /32, ei ole linkin vertaista ja se lähettää jokaisen kohteen oletusreittinsä kautta.

ip -4 addr show tun0
ip route get 192.168.50.20

Asiakas, joka yhdistää kotireitittimestä samaa aluetta käyttäen, yhdistää ja saavuttaa sitten lähes ei mitään. Asiakas pitää paikallisen reittinsä tuolle etuliitteelle, joten tunneliosoite törmää sen takana olevaan verkkoon ja liikenne lähtee väärästä rajapinnasta. Tätä tapausta ei voi korjata palvelimella; dokumentoitu keino on kotiverkon uudelleennumerointi tai riittävän kaukana olevan poolialueen valinta, jotta törmäykset pysyvät harvinaisina. Kirjaa sekä vika että keino, koska tukipalvelu kohtaa sen uudelleen.

Yhdistä sama asiakas uudelleen ja seuraa osoitetta. Dynaaminen pooli voi palauttaa saman tai eri arvon ja molemmat ovat oikein, kun taas identiteettikohtainen pooli, joka muuttaa osoitetta, ei noudata sidontaa. Tarkistus kestää sekunteja ja ratkaisee, onko ensimmäisessä osiossa kirjaamasi tila voimassa oleva tila.

Seuraa vastausta takaisin palvelusta

Pooli toimii vain, kun vastaukset voivat matkustaa takaisin siihen. LANissa oleva palvelu vastaa sisäiseen osoitteeseen, joten sen yhdyskäytävä tarvitsee reitin poolille tai käännöksen palvelun eteen. Kun pyyntö saapuu tunnelin kautta ja vastaus lähtee eri polkua, tilallinen palomuuri tai käänteisen reitin tarkistus pudottaa sen, ja asiakas näkee palvelun, joka yhdistää ja sitten jumittuu. Laita pooli reitityssuunnitelmaan yhtenä tiivistettävänä lohkona sen sijaan, että lisäät reittejä isäntäkohtaisesti.

Käännös muuttaa sitä, mitä muut järjestelmän osat näkevät. Kun lähde kirjoitetaan uudelleen, isäntäpalomuurissa ja sovelluslokissa oleva osoite on käännetty, joten poolin osoitteen mukaan kirjoitettu sääntö ei vastaa mitään eikä lokiriviä voi jäljittää asiakkaaseen. strongSwanin välitysdokumentaatio kattaa tuon polun palvelinpuolen osuuden IKEv2-yhdyskäytävälle. DNS kantaa saman rajoituksen, koska nimi, joka ratkeaa osoitteeksi, johon asiakas ei pääse, epäonnistuu myöhemmin ja toisaalla.

Kaksi asiakasta, sitten yksi peruutus

Yhdistä kaksi asiakasta samanaikaisesti ja lue molemmat osoitteet. Niiden on oltava erillisiä, käyttökelpoisia ja poolin sisällä, ja kummankin on päästävä palveluun, johon se on tarkoitettu. Pooli, joka jakaa kaksoisosoitteita, näkyy yleensä täällä, ei ensimmäisessä yhden asiakkaan testissä.

Peruuta yksi valtuustieto, kun toinen asiakas pysyy yhdistettynä, ja kokeile sitten palvelua selvinneestä asiakkaasta. Peruutus, joka häiritsee toista istuntoa, viittaa jaettuun tilaan, useimmiten yhteen valtuustietoon tai yhteen osoitteeseen, jota käytetään uudelleen laitteiden välillä. Yhdistä peruutettu asiakas uudelleen ja varmista, että se hylätään sen sijaan, että sille annettaisiin vapautettu osoite.

Lopeta kohteeseen, joka pitäisi kieltää. Asiakas, joka saavuttaa kaiken, on yhdistetty, ei testattu.

Kirjoita neljä arvoa sinne, mistä seuraava muutos ne löytää

Muistiinpano on lyhyt: poolin alue ja etuliite, osoitustila, paluupolku tai käytössä oleva käännös ja DNS-laajuus, joka vastaa noista kohteista. Laita se palvelinkonfiguraation viereen äläkä tikettiin, ja päivää se. Jokainen, joka myöhemmin muuttaa yhtä neljästä, tarvitsee muut kolme eteensä, koska poolin koon muutos rikkoo reitin ja reitin muutos rikkoo DNS-vastauksen.

Pidä omistajuusmerkintä sen mukana: tunnelialue kuuluu VPN-palvelimelle, ja LANin DHCP-alueelle tehty varaus ei varaa mitään tunnelin sisällä olevalle asiakkaalle. Se yksi rivi estää yleisimmän uudelleentyön, jossa joku lisää varauksen ja odottaa tunneliosoitteen seuraavan sitä.