DS-Lite estää saapuvan IPv4-hostingin, ei lähtevää VPN:ää

DS-Lite on tapa antaa asiakkaalle IPv4-yhteys sellaisen liityntäverkon kautta, joka kuljettaa vain IPv6:ta. Kotireitittimellä ei ole omaa erillistä julkista IPv4-osoitetta, ja tämä yksi tosiasia saa ihmiset uskomaan, ettei IPv4 VPN voi toimia kyseisestä yhteydestä. Lähtevään suuntaan se yleensä toimii hyvin. Palveluntarjoaja kääntää yhteyden, ja kaukopää näkee tavallisen IPv4-asiakkaan. Rikki menee vastakkainen suunta: sellaisen asian hosting, joka odottaa pyytämätöntä saapuvaa IPv4:ta. Ero on siinä, kumpi pää aloittaa keskustelun.

Kumpi pää aloittaa yhteyden

Yhteyden aloittava asiakas luo käännöstilaa sitä mukaa kun se etenee. Palveluntarjoajan kääntäjä näkee ensimmäisen paketin, varaa mappauksen ja välittää sen eteenpäin. Paluuliikenne vastaa tuota mappausta, koska mappaus on jo olemassa.

Yhteyksiä odottavalla palvelimella ei ole sellaista tilaa luotavaksi. Jonkun ulkopuolisen on päästävä osoitteeseen ja porttiin, jota palveluntarjoaja ei ole suostunut mappaamaan, ja se on täysin eri pyyntö.

Seuraa lähtevää pyyntöä

Arkkitehtuuri RFC 6333 nimeää molemmat päät. Asiakkaan puolen elementti on B4, joka kapseloi IPv4:n IPv6:een. Palveluntarjoajan puolen elementti on AFTR, joka tekee osoitteen käännön ja välittää paketin IPv4:na.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN-palvelin vastaanottaa tavallisen IPv4-yhteyden palveluntarjoajan käännetystä osoitteesta. Se ei tarvitse DS-Lite-tilaa, erityistä porttia tai mitään tietoa siitä, että asiakkaan liityntäverkko on vain IPv6. Juuri tämän ihmiset ohittavat: kaukopää ei voi tietää sitä.

Asiakkaan oma kokoonpano on yhtä tavallinen. Se tarvitsee toimivan IPv4-reitin palvelimelle, jonka B4 ja AFTR tarjoavat, ja sen on saatava palvelimen isäntänimi ratkeamaan IPv4-osoitteeksi.

Miksi saapuva hosting on se tapaus, joka epäonnistuu

IPv4 VPN -palvelimen ajaminen kotona on ratkaisu, joka törmää palveluntarjoajan jaettuun osoitteistukseen. Palveluntarjoajan kääntäjä omistaa julkisen osoitteen ja mappaustaulun, eikä sillä ole syytä luoda pysyvää saapuvaa mappausta yhdelle tilaajalle.

Kotireitittimen portin edelleenohjaussääntö ei voi määrittää AFTR:ää. Sääntö on todellinen ja oikea paikallisella laitteella, eikä se muuta mitään ylävirtaan, siksi oire näyttää palomuuriongelmalta, joka ei poistu.

Tässä myös operaattoritason käännös eroaa yhdestä julkisesta osoitteesta: jopa oikea paikallinen edelleenohjaus voi päätyä osoitteeseen, jonka monet tilaajat jakavat.

Diagnosoi ennen liittymäsuunnitelman muuttamista

Vahvista ensin provisionoitu tila. Natiivi kaksoispino, DS-Lite ja vain IPv6:ta käyttävä verkko, joka käyttää toista käännösmekanismia, ovat kolme eri järjestelyä, eivätkä palveluntarjoajan markkinointinimet aina vastaa teknistä.

Aseta sitten neljä havaintoa lähtevälle vialle. Ratkaiseeko asiakas VPN:n isäntänimen IPv4-kohteeksi? Toimiiko pelkkä IPv4-yhteys, eikä selainpyyntö, joka on ehkä hiljaa käyttänyt IPv6:ta? Mitä kuljetusta ja porttia asiakas yrittää, ja näkevätkö päätepisteen lokit yrityksen lainkaan? Tapahtuuko vika alkuvaihdossa, joutokauden jälkeen vai vain suuremmissa siirroissa?

Nuo neljä vastausta viittaavat suodatukseen, käännöstilan vanhenemiseen, väärään päätepisteeseen tai paketin koon käsittelyyn. Mitään niistä ei todisteta näkemällä DS-Lite tilisivulla.

Lue palveluntarjoajan muutokset huolellisesti

Tilimuutos voi osua yhteen toimivan yhteyden kanssa ja muuttaa samalla useita ominaisuuksia kerralla. Kirjaa, mikä ominaisuus muuttui, koska uusi paketin nimi ei ole tekninen selitys.

Ohje kaksoispinon käyttöönotosta on monitulkintainen, kunnes joku vahvistaa, mitä palveluntarjoaja todella provisionoi. Sen pitäminen yleisenä vaatimuksena IPv4 VPN -asiakkaille muuttaa arvauksen käytännöksi.

Jos todellinen vaatimus on saapuva IPv4-hosting, keskustele palveluntarjoajan kanssa tuetusta saapuvasta järjestelystä, natiivista osoitteistuksesta tai toisesta liittymäratkaisusta. Jos vaatimus on kannettava tietokone, joka tavoittaa etäpalvelimen, kysy sen sijaan juuri siitä lähtevästä virrasta. Työjärjestys: nimeä suunta, vahvista provisionoitu tila, testaa pelkkää IPv4:ta ja yhtä kuljetusta ja muuta liittymäsuunnitelmaa vain, jos suunta todella vaatii sitä.