Kysymys kuulostaa yhdeltä haulta, mutta todellisuudessa kyse on kolmesta päätöksestä. Minkä reitin binding request ottaa, minkä lähteen ydin valitsee sille reitille ja kirjoittaako jokin matkalla sen lähteen uudelleen. Muuta mitä tahansa kolmesta, niin osoite, jonka STUN-palvelin ilmoittaa, muuttuu mukana. Siksi väite, että VPN on reitittimessä, ei itsessään kerro juuri mitään.

Päätös nojaa kolmeen tosiasiaan

Ensinnä reitti: käytäntösäännöt ja reititystaulu päättävät, lähteekö pyyntö tunnelin vai tavallisen WAN:n kautta, ja suljettu kohde valitsee toisen polun myös tunnelin ollessa aktiivinen. Toiseksi lähde: ydin valitsee lähteen valitulle reitille, ja valinta riippuu reitin ensisijaisesta lähteestä ja jokaisesta täsmänneestä säännöstä. Kolmanneksi käännös: NAT matkalla korvaa valitun lähteen. Heijastettu osoite on kaikkien kolmen tulo, ei tunnelin ominaisuus.

Muuta yhtä kolmesta, niin vastaus muuttuu, vaikka jokainen komponentti näyttää omassa lokissaan edelleen terveeltä. Se on tavallinen syy siihen, miksi tämä diagnoosi jumittuu.

Kirjaa kolme tosiasiaa testattavasta virrasta ennen aloittamista. Liitännän, reitin ja käännössäännön avulla tuloksen voi ennustaa, ja juuri ennustaminen tekee yllätyksestä informatiivisen. Jos et pysty täyttämään yhtä kolmesta, se aukko on varsinainen löydös.

Seuraa yhtä binding requestia polun läpi

STUN binding request pyytää palvelinta ilmoittamaan havaitsemansa lähteen kuljetusosoitteen. Vastaus kuvaa polun, jonka pyyntö kulki, ei luetteloa asiakaskoneen liitännöistä. Kaksi pyyntöä kahta polkua pitkin ilmoittaa rehellisesti kaksi eri osoitetta.

Path takenSource the reflector seesWhat it means
Tunnel to a public exit that translatesThe exit's public addressThe reflector learns nothing about the LAN
Tunnel to a private reflector, translated to the tunnel address, no later translationThat tunnel addressAn internal identifier is disclosed to that reflector
Excluded flow over the ordinary WANThe WAN addressThe tunnel was not used at all

Lue taulukko ehtojoukkona, älä tarjoajien valikkona. Keskimmäinen rivi edellyttää, että yksityinen heijastin on tavoitettavissa tunnelin oman reitityksen ja peer-käytännön alla; se on konfiguraatiotieto, jonka voit tarkistaa, ei jotain, mitä tili taso edellyttää. Alin rivi on yleensä käytännön kannalta tärkein, koska sen liikenteen piti pysyä tunnelissa. Niiden välissä on tavallinen tapaus, jossa uloskäynti kääntää ja heijastin näkee vain uloskäynnin.

Isäntäkandidaatit ja palvelinheijastavat kandidaatit tulevat eri mekanismeista, joten kandidaattiluettelo ei kerro, mitä polkua media todella käytti. Lue valittu pari, älä keräyslokia, kun haluat tietää, minne istunto meni.

Mikä reitittimen tunneliosoite ei ole

Reitittimelle osoitettu tunneliosoite kuuluu reitittimen liitännälle. LAN-isännän selaimella on omat liitäntäosoitteensa eikä suoraa näkymää reitittimen tunneliliitäntään. Jos niitä kohdellaan vaihdettavina, syntyy itsevarmoja vääriä vastauksia siitä, mitä verkkosivu voi oppia.

Edelleenlähetys on se, mikä ne yhdistää. Pyyntö kulkee reitittimen läpi reititettynä liikenteenä, ja sen lähde on se, minkä reititys ja käännös tuottivat.

Jos tunnelipolku säilyttää LAN-lähteen, yksityinen heijastin voi oppia sen LAN-osoitteen, mikä on todellinen paljastus ja eri kuin tunneliosoite. Jos polku kääntää tunneliosoitteeksi, heijastin oppii sen sijaan tunneliosoitteen. Molemmat tulokset sopivat samaan selaimeen samassa isännässä, siksi havainto on sidottava tiettyyn virtaan. Kysy ytimeltä, mitä lähdettä se käyttäisi, ennen kuin syytät sovellusta.

Paljastus vastaan ohitus: kaksi löydöstä, kaksi korjausta

Heijastettu tunneliosoite paljastaa sisäisen tunnisteen polulla, jonka sallit. Suora WAN-pyyntö ohittaa polun, jota halusit vaatia. Ensimmäinen on tietokysymys, toinen toimeenpanokysymys, ja ne korjataan eri paikoissa. Jos ne sulauttaa yhteen sanaan, syntyy korjaus, joka ei käsittele kumpaakaan.

WebRTC tekee tästä näkyvämpää tekemättä siitä väärää, sillä kandidaatin kerääminen ei ole sama kuin sen valitseminen.

ip route get 203.0.113.7 from 192.0.2.25
ip rule show

Aja reittikysely jokaiselle sallitulle heijastinosoitteelle lähteellä, jonka odotat virran kantavan, ja aja se sitten uudelleen suljetuille alueille nähdäksesi, mitä varavaihtoehto valitsee. Vertaa kahta vastausta kirjaamaasi käytäntöön. Kun ne eroavat tavalla, jota et tarkoittanut, olet löytänyt korjauskohdan ilman, että sinun tarvitsee tulkita selaimen kandidaattiluetteloa lainkaan.

Aiheeseen liittyvät artikkelit