Sümmeetriline NAT ja VPN: mõõtke vastendust, mitte silti
Lõpp-punktist sõltuv vastendus mõjutab võrdsete avastamist, mitte tavalist klient-serveri tunnelit. Mõõtke port ja kui otsetee ebaõnnestub, kasutage releed.
Kui tugilõim lõpeb otsusega „sümmeetriline NAT, VPN siin ei tööta”, installitakse klient seejärel kolm korda ilma põhjuseta uuesti. Silt teeb kahju, sest vastab küsimusele, mida keegi ei küsinud. Klient, mis ühendub väljapoole fikseeritud serveriga, loob vastenduse hetkel, mil saadab esimese paketi, ja vastus lastakse tagasi reeglite järgi, mida rakendab peaaegu iga võrk. Mida lõpp-punktist sõltuv vastendus tegelikult keeruliseks teeb, on kaks võrdset, kes püüavad samal ajal teineteiseni jõuda, ja see on teine katse.
Ühe sildi taga peitub kaks küsimust
Esimene küsimus on, kas selle võrgu taga olev host saab avada sessiooni teadaolevale avalikule aadressile ja pordile. Tunneli kliendi jaoks on see tavaline juhtum ja vastus on peaaegu alati jah. Ruuter registreerib sisemise allika, eraldab välise pordi ja laseb vastuse läbi, sest see kuulub seansile, mis algas seestpoolt.
Teine küsimus on, kas kaks eri võrkude taga olevat hosti suudavad leida ühise tee ja saata teineteisele ilma vahepealse serverita. See sõltub sellest, kuidas iga võrk neid väliseid porte eraldab, ja ainult seal on vastenduse käitumisel tähtsust.
Kahe segamine annab klassikalise vale diagnoosi: võrdsete funktsioon ebaõnnestub, keegi käivitab NAT-tüübi testi, näeb halvimat kategooriat ja järeldab, et ka tavaline tunnel ei saa töötada. Tunnel ei olnud kunagi see, mis ebaõnnestus.
Vastendus ja filtreerimine on eraldi omadused
RFC terminoloogia on täpsem kui tarnijate kasutatud nimed ja seda tasub piletisse kanda, sest see lahendab vaidlusi. Vastendus on see, kuidas väline port eraldatakse. Filtreerimine on see, millised sissetulevad paketid läbi lastakse. Võrk võib olla ühes range ja teises liberaalne, ning just see kombinatsioon on see, millele võrdsete protokoll peab vastu pidama.
| 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 rida on see, mida enamik tarbijaruutereid ja mobiilioperaatoreid sümmeetrilise all mõtlevad. Pange tähele, et silt kirjeldab ainult eraldamist. Sellise vastenduse ja liberaalse filtreerimisega võrk võib siiski vastu võtta sissetulevaid pakette porti, mille ta just eraldas, ja seetõttu õnnestub aukude puurimine mõnel neist ja ebaõnnestub teistel.
Filtreerimisel on oma kolm juhtumit ja igaühe jaoks oma nimi. Kirjutada piletisse „sümmeetriline NAT”, kui mõtlete „aadressist ja pordist sõltuv filtreerimine”, saadab järgmise inimese käsiraamatu valesse peatükki. Need kaks käituvad testis erinevalt, seega pole viga akadeemiline.
Mõõtke vastendust, selle asemel et seda nimetada
Eraldatud porti saate jälgida otse iga teie juhitava UDP-teenuse serveripoolelt. Alustage püüdmist avalikus hostis, saatke kliendist ja lugege välja lähteport, millega pakett saabus:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820Lõpp-punkti rida on kolmest kõige kasulikum, sest WireGuard registreerib viimase aadressi ja pordi, mille ta igalt võrdselt sai. Võrrelge seda porti sellega, mida klient arvab end kasutavat. Need erinevad alati, kui toimub mingi tõlge, ja tähtis küsimus on, kas väärtus jääb stabiilseks.
Korrake vaatlust teise sihtpordi või teise serveri vastu ja võrrelge uuesti. Kui väline port muutub sihtkoha kaupa, sõltub vastendus aadressist ja pordist. Kui see jääb samaks, annab võrk teile ühe vastenduse ja avastamisel on šanss.
STUN-põhised tööriistad teatavad sama klassifikatsiooni ühe sammuga ja neid võib kasutada, kui võrk lubab väljuvat UDP-d avalikku STUN-serverisse. Kui ei luba, töötab ülaltoodud püüdmismeetod endiselt ja ei nõua muud kui host, mida te juba juhite.
Valige tõrkega sobiv parandus
Kui tõrkav funktsioon on võrdsete oma, on toetatud vastused relee, kohtumisteenus, milleni mõlemad võrdsed jõuavad, või teistsugune topoloogia. TURN on täpselt selle jaoks olemas ja toode, mis tarnib oma relee, ütleb teile, et ootab mõne võrgu vaenulikkust.
Kui tõrkav funktsioon on tavaline tunnel, ei ole vastenduse käitumine teie probleem ja ükski ülaltoodu ei kehti. Kontrollige, et klient tõesti saadab, et server näeb paketti ja et vastus tuleb tagasi. See jada on kolm vaatlust ja see ei nõua teadmisi ruuteri NAT-kategooriast.
Mis ei tööta, on kohalike pordimuudatuste laialilaotamine, kuni midagi ühendub. Kliendi lähtepordi muutmine ei muuda seda, kuidas võrk vastendusi eraldab. Juhuslik edu viiendal katsel on vale-positiivne ja seda tsiteeritakse lahendusena kuude kaupa.
Kirjutage üles arhitektuur, mitte otsus
Kasulik märge ütleb, milline protokoll, mis suunas seanss algab, kas teel on relee ja mida juhtmel täheldati. „sümmeetriline NAT, ei tööta” on kasutu, sest see on korraga vale tunneli kohta ja mitteinformatiivne võrdse tee kohta.
Lisage mõõdetud pordi stabiilsus ja filtreerimise käitumine, kui te neid testisite. Need kaks fakti lubavad kellelgi teisel ennustada, kas uus funktsioon selles võrgus töötab, ilma kogu uurimist kordamata. Need vananevad ka paremini kui tarnija kategooria, mis tähendab igal abilehel pisut erinevat asja.
Lõpuks hoidke RFC 4787 terminoloogiat käepärast, kui seda kirja panete. Täpsete terminite kasutamine maksab ühe lause ja takistab järgmisel lugejal sama vale diagnoosi kordamast, ja see ongi märkme kirjutamise mõte.