IPv6-osoitteet eivät korvaa VPN:ääsi: käy alkuperäinen tehtävä läpi

Avaa asiakkaan tilasivu, näe globaali IPv6-osoite, ja kiusaus on päätellä, että tunnelista on tullut valinnainen. Se sivu näyttää osoitteen, ei salausrajaa, ei yksityistä reititystaulua eikä käyttöoikeuspäätöstä. VPN hoitaa yleensä kolmea tehtävää yhtä aikaa, ja IPv6 koskee vain sitä, joka liittyy niukkojen osoitteiden jakamiseen. Yhden palvelun kulkeminen asiakkaasta kuuntelijaan on ainoa tapa nähdä, mikä tehtävä säilyy muutoksen jälkeen.

Nimeä tehtävä ennen työkalun poistamista

Ihmiset sanovat ”VPN”, kun tarkoittavat yhtä kolmesta järjestelystä, ja kaikki kolme epäonnistuvat eri syistä. Yhden tiimin julkaisemaan sovellukseen pääseminen on sovelluskäyttöongelma. Liittyminen määriteltyyn yksityisverkkojen joukkoon, jotta useat toimipaikat tavoittavat toisensa, on reitityssuhde. Vakaan hallintakerroksen pitäminen infrastruktuurin päällä, jota et täysin hallitse, on oma osoitesuunnitelmansa omaava toimintajärjestely.

IPv6 poistaa osoitteiden jakamisen esteen ensimmäiseltä järjestelyltä, ja siinä se tekee todellista työtä, koska suora osoite voi korvata kääntäjän. Kahdelle muulle se ei muuta mitään, koska vaatimus ei koskaan ollut osoitteiden niukkuus. Kirjoita muistiin, mitä kolmesta todella ajat, ennen kuin kosket asetukseen.

Julkinen osoite ei ole salausta

Globaalin laajuuden osoite kertoo, mistä isäntä on tavoitettavissa; se ei kerro mitään siitä, onko sinne saapuva liikenne salattua vai todennettua. RFC 8504:n turvakeskustelu erottaa IPsec-toteutuksen tuen laajemmasta valinnasta IPsecin, TLS:n, SSH:n ja muiden lähestymistapojen välillä, ja juuri se ero katoaa, kun tavoitettavuus luetaan suojaukseksi. Pino, joka tukee mekanismia, on todistanut vain, että mekanismi on saatavilla, ei koskaan sitä, että tämä virta kulki sen kautta. IPsecin osalta neuvoteltu assosiaatio ja sen valitsema liikenne ratkaisevat, mitä suojataan, ja osoiteperhe on paketin ominaisuus, ei sen käytäntö.

Tavoitettavuus on jälleen erillinen kysymys. Julkinen osoite ei saa odottamatonta liikennettä saapumaan, koska reitillä, palomuurilla ja kuuntelijalla on kullakin äänensä, ja NAT:n poistaminen poistaa yhden suodattimen, ei kaikkia. Päätä, mitä kolmesta tunneli korvasi, jos mitään.

Mitä päällekkäisverkko yhä tarjoaa

Päällekkäisverkko ansaitsee paikkansa edelleen kolmessa tilanteessa. Etäkäyttäjät voivat tarvita tietyn reittijoukon yhden sovelluksen sijaan, kaksi toimipaikkaa voivat tarvita yksityisen tavoitettavuussopimuksen, ja operaattorit voivat haluta osoitteistuksen, joka ei muutu, kun yhteyspalveluntarjoaja vaihtuu. Mikään kolmesta ei liity IPv4-osoitteiden niukkuuteen.

Globaalit osoitteet eivät tee siitä huoltovapaata. Siisti sisäinen suunnitelma ei pidä ulkoista päätepistettä vastaamassa sen jälkeen, kun palveluntarjoaja muuttaa sitä, ja todennus, uudelleenyhdistäminen ja nimien päivitykset tarvitsevat edelleen omistajan. Päätä, miten ne palautuvat, ennen kuin mitään kytketään pois.

Käy läpi palvelu, josta tulee julkinen

Aloita isännästä ja luettele, mikä todella kuuntelee, koska hyväksymäsi sovellus on harvoin ainoa asia koneella. ss -lntup tulostaa jokaisen TCP- ja UDP-kuuntelijan sidontaosoitteineen ja lisää omistavan prosessin, jos oikeutesi sallivat, mikä näyttää yhdellä silmäyksellä, onko hallintaliittymä jokeriosoitteessa vai vain loopbackissa. Toista se muodossa ss -6 -lntup, jos pinosi pitää IPv6-pistokkeet erillään.

Luokittele sitten jokainen rivi yleisön mukaan. Sovellusportti, jolla on oma todennus ja kuljetusturva, voi olla kunnossa julkisessa osoitteessa, kun taas hallintaliittymä, mittareiden päätepiste ja tietokantaportti eivät yleensä ole. Yksi hyväksytty sovellus on arvio vain siitä sovelluksesta, ei koskaan lupa paljastaa jokaista isäntää jakavaa palvelua. Kunkin rivin sidontaosoite kertoo, onko paljastus jo olemassa vai syntyisikö se suunnittelemastasi muutoksesta.

Kaksi testiä, päätä sitten mitä kytket pois

Ennen kerroksen poistamista vastaa kahteen kysymykseen paperilla. Ensinnäkin, tarvitseeko vaatimus yksityistä reititystä eli tavoitettavuutta, jota julkinen osoite ei sisällä ja jota yhteyspalveluntarjoaja ei tarjoa? Toiseksi, tarvitseeko se suojausrajan eli salauksen ja todennuksen virralle, joka muuten ylittäisi epäluotettavan polun selvänä? Jos molemmat vastaukset ovat tuolle palvelulle ei, tunneli on poistamisen ehdokas; jos jompikumpi on kyllä, se jää.

Aja sama testi IPv4:lle ja IPv6:lle erikseen kaksoispinon asiakkaalla, koska suojattu IPv4-liikenne ei kerro mitään IPv6-polusta. Globaali IPv6-osoite tilasivulla ei ole todiste vuodosta, eikä sen puuttuminen ole todiste suojauksesta. Kytke pois vain palvelut, joille molemmat vastaukset kirjattiin ja ovat edelleen ei, ja kirjaa muutosrekisteriin, mikä kysymys sen ratkaisi.