Symmetrinen NAT ja VPN: mittaa mappaus, älä nimikettä
Päätepisteestä riippuva mappaus vaikuttaa vertaisten löytämiseen, ei tavalliseen asiakas-palvelin-tunneliin. Mittaa portti ja käytä sitten välittäjää, jos suora polku epäonnistuu.
Tukiketju päättyy tuomioon ”symmetrinen NAT, VPN ei tule toimimaan täällä”, ja sen jälkeen asiakas asennetaan kolme kertaa uudelleen ilman syytä. Nimike aiheuttaa vahinkoa, koska se vastaa kysymykseen, jota kukaan ei esittänyt. Asiakas, joka yhdistää ulospäin kiinteään palvelimeen, luo mappauksen heti lähettäessään ensimmäisen paketin, ja vastaus päästetään takaisin säännöillä, jotka lähes jokainen verkko toteuttaa. Mitä päätepisteestä riippuva mappaus todella monimutkaistaa, on kaksi vertaista, jotka yrittävät päästä toisiinsa samanaikaisesti, ja se on toinen testi.
Yhden nimikkeen takana piilee kaksi kysymystä
Ensimmäinen kysymys on, voiko tämän verkon takana oleva isäntä avata istunnon tunnettuun julkiseen osoitteeseen ja porttiin. Tunneliasiakkaalle se on tavallinen tapaus, ja vastaus on lähes aina kyllä. Reititin kirjaa sisäisen lähteen, jakaa ulkoisen portin ja päästää vastauksen läpi, koska se kuuluu istuntoon, joka alkoi sisältä.
Toinen kysymys on, voivatko kahden eri verkon takana olevat isännät löytää yhteisen polun ja lähettää toisilleen ilman välissä olevaa palvelinta. Se riippuu siitä, miten kukin verkko jakaa nuo ulkoiset portit, ja vain siinä mappauksen käyttäytymisellä on merkitystä.
Kahden sekoittaminen tuottaa klassisen väärän diagnoosin: vertaisten välinen ominaisuus epäonnistuu, joku ajaa NAT-tyyppitestin, näkee huonoimman luokan ja päättelee, ettei tavallinen tunneli voi sekään toimia. Tunneli ei ollut koskaan se, mikä epäonnistui.
Mappaus ja suodatus ovat erillisiä ominaisuuksia
RFC:n terminologia on täsmällisempi kuin toimittajien käyttämät nimet, ja se kannattaa siirtää tikettiin, koska se ratkaisee kiistat. Mappaus on se, miten ulkoinen portti jaetaan. Suodatus on se, mitkä saapuvat paketit päästetään läpi. Verkko voi olla tiukka toisessa ja salliva toisessa, ja juuri se yhdistelmä on se, mikä vertaisten välisen protokollan on selvittävä.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
Kolmas rivi on se, mitä useimmat kuluttajareitittimet ja matkapuhelinoperaattorit tarkoittavat symmetrisellä. Huomaa, että nimike kuvaa vain jakoa. Verkko, jossa on tuo mappaus ja salliva suodatus, voi silti ottaa vastaan saapuvia paketteja porttiin, jonka se juuri jakoi, ja siksi reiän puhkaisu onnistuu joillakin ja epäonnistuu toisilla.
Suodatuksella on omat kolme tapaustaan ja oma nimensä kullekin. ”symmetrinen NAT” tikettiin kirjoittaminen, kun tarkoittaa ”osoitteesta ja portista riippuvaa suodatusta”, lähettää seuraavan ihmisen käsikirjan väärään lukuun. Kaksi käyttäytyy testissä eri tavoin, joten virhe ei ole akateeminen.
Mittaa mappaus sen nimeämisen sijaan
Voit havainnoida jaetun portin suoraan minkä tahansa hallitsemasi UDP-palvelun palvelinpuolelta. Aloita kaappaus julkisella isännällä, lähetä asiakkaalta ja lue lähdeportti, jolla paketti saapui:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820Päätepisterivi on kolmesta hyödyllisin, koska WireGuard kirjaa viimeisen osoitteen ja portin, jonka se vastaanotti kullakin vertaiselta. Vertaa tuota porttia siihen, jota asiakas luulee käyttävänsä. Ne eroavat aina, kun mitä tahansa käännöstä tapahtuu, ja tärkeä kysymys on, pysyykö arvo vakaana.
Toista havainto toista kohdeporttia tai toista palvelinta vastaan ja vertaa uudelleen. Jos ulkoinen portti vaihtuu kohteen mukaan, mappaus riippuu osoitteesta ja portista. Jos se pysyy samana, verkko antaa yhden mappauksen ja löytämisellä on mahdollisuus.
STUN-pohjaiset työkalut raportoivat saman luokituksen yhdessä vaiheessa, ja niitä voi käyttää, kun verkko sallii lähtevän UDP:n julkiseen STUN-palvelimeen. Kun ei salli, yllä kuvattu kaappausmenetelmä toimii edelleen eikä vaadi muuta kuin isännän, jota jo hallitset.
Valitse vikaan sopiva korjaus
Jos epäonnistuva ominaisuus on vertaisten välinen, tuetut vastaukset ovat välittäjä, kohtaamispalvelu, johon molemmat vertaiset pääsevät, tai erilainen topologia. TURN on olemassa juuri tätä varten, ja tuote, joka toimittaa oman välittäjänsä, kertoo sinulle odottavansa joidenkin verkkojen olevan vihamielisiä.
Jos epäonnistuva ominaisuus on tavallinen tunneli, mappauksen käyttäytyminen ei ole sinun ongelmasi eikä mikään yllä olevasta päde. Tarkista, että asiakas todella lähettää, että palvelin näkee paketin ja että vastaus palaa. Tämä järjestys on kolme havaintoa, eikä se vaadi tietoa reitittimen NAT-luokasta.
Se, mikä ei toimi, on paikallisten porttimuutosten levittäminen, kunnes jokin yhdistyy. Asiakkaan lähdeportin muuttaminen ei muuta sitä, miten verkko jakaa mappauksia. Satunnainen onnistuminen viidennellä yrityksellä on väärä positiivinen, ja sitä siteerataan korjauksena kuukausien ajan.
Kirjaa arkkitehtuuri, älä tuomiota
Hyödyllinen muistiinpano kertoo, mikä protokolla, mihin suuntaan istunto alkaa, onko polulla välittäjä ja mitä johdolla havaittiin. ”symmetrinen NAT, ei toimi” on käyttökelvoton, koska se on samanaikaisesti väärä tunnelin suhteen ja kertomatta mitään vertaisen polusta.
Sisällytä mitattu portin vakaus ja suodatuksen käyttäytyminen, jos testasit ne. Nämä kaksi tosiasiaa antavat jonkun muun ennustaa, toimiiko uusi ominaisuus siinä verkossa toistamatta koko tutkimusta. Ne myös vanhenevat paremmin kuin toimittajaluokka, joka tarkoittaa joka ohjesivulla hieman eri asiaa.
Pidä lopuksi RFC 4787:n terminologia käsillä, kun kirjoitat sen. Täsmällisten termien käyttö maksaa yhden lauseen ja estää seuraavaa lukijaa toistamasta saman väärän diagnoosin, ja juuri se on muistiinpanon kirjoittamisen koko pointti.