Simetria NAT kaj VPN: mezuru la mapadon, ne la etikedon
Mapado dependa de finpunkto influas samrangan malkovron, ne ordinaran klient-al-servila tunelon. Mezuru la pordon kaj poste uzu relajson se la rekta vojo malsukcesas.
Subtena fadeno finiĝas per la verdikto „simetria NAT, la VPN ĉi tie ne funkcios”, kaj poste la kliento estas tri fojojn senkaŭze reinstalita. La etikedo kaŭzas damaĝon ĉar ĝi respondas demandon, kiun neniu starigis. Kliento, kiu konektiĝas eksteren al fiksa servilo, kreas mapadon en la momento, kiam ĝi sendas la unuan paketon, kaj la respondo rajtas reveni laŭ reguloj, kiujn preskaŭ ĉiu reto efektivigas. Kion mapado dependa de finpunkto vere komplikigas, estas du samranguloj provantaj atingi unu la alian samtempe, kaj tio estas alia testo.
Du demandoj kaŝiĝas malantaŭ unu etikedo
La unua demando estas, ĉu gastiganto malantaŭ ĉi tiu reto povas malfermi sesion al konata publika adreso kaj pordo. Por tunela kliento tio estas la normala kazo, kaj la respondo preskaŭ ĉiam estas jes. La enkursigilo registras la internan fonton, atribuas eksteran pordon kaj lasas la respondon trapasi ĉar ĝi apartenas al sesio komencita de interne.
La dua demando estas, ĉu du gastigantoj malantaŭ malsamaj retoj povas malkovri komunan vojon kaj sendi unu al la alia sen servilo meze. Tio dependas de tio, kiel ĉiu reto atribuas tiujn eksterajn pordojn, kaj nur tie la konduto de la mapado gravas.
Konfuzi la du aferojn produktas la klasikan misdiagnozon: samranga funkcio malsukcesas, iu rulas teston de NAT-tipo, vidas la plej malbonan kategorion kaj konkludas, ke ankaŭ la ordinara tunelo ne povas funkcii. La tunelo neniam estis tio, kio malsukcesis.
Mapado kaj filtrado estas apartaj ecoj
La terminologio de RFC estas pli preciza ol la nomoj, kiujn uzas vendistoj, kaj indas porti ĝin en la bileton ĉar ĝi solvas disputojn. Mapado estas kiel la ekstera pordo estas atribuata. Filtrado estas kiuj envenantaj paketoj rajtas trapasi. Reto povas esti severa en unu kaj malstrikta en la alia, kaj tiu kombinaĵo estas tio, kion samranga protokolo devas postvivi.
| 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 |
La tria vico estas tio, kion la plej multaj konsumantaj enkursigiloj kaj poŝtelefonaj operatoroj komprenas per simetria. Rimarku, ke la etikedo priskribas nur la atribuon. Reto kun tiu mapado kaj malstrikta filtrado ankoraŭ povas akcepti envenantajn paketojn al la pordo, kiun ĝi ĵus atribuis, kaj tial truoborado sukcesas ĉe kelkaj kaj malsukcesas ĉe aliaj.
Filtrado havas siajn proprajn tri kazojn kaj sian propran nomon por ĉiu. Skribi „simetria NAT” en bileton, kiam vi celas „filtrado dependa de adreso kaj pordo”, sendas la sekvan personon al la malĝusta ĉapitro de la manlibro. La du kondutas malsame en testo, do la eraro ne estas akademia.
Mezuru la mapadon anstataŭ nomi ĝin
Vi povas observi la atribuitan pordon rekte de la servila flanko de iu ajn UDP-servo, kiun vi kontrolas. Komencu kaptadon sur la publika gastiganto, sendu de la kliento kaj legu la fontan pordon, kun kiu la paketo alvenis:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820La finpunkta linio estas la plej utila el la tri, ĉar WireGuard registras la lastan adreson kaj pordon, kiujn ĝi ricevis de ĉiu samrangulo. Komparu tiun pordon kun tiu, kiun la kliento kredas uzi. Ili malsamos ĉiam, kiam okazas iu ajn traduko, kaj la grava demando estas, ĉu la valoro restas stabila.
Ripetu la observon kontraŭ dua celloka pordo aŭ dua servilo kaj komparu denove. Se la ekstera pordo ŝanĝiĝas laŭ celloko, la mapado dependas de adreso kaj pordo. Se ĝi restas sama, la reto donas al vi unu mapadon kaj la malkovro havas ŝancon.
Iloj bazitaj sur STUN raportas la saman klasifikon en unu paŝo, kaj ili estas taŭgaj uzi, kiam la reto permesas elirantan UDP al publika STUN-servilo. Kiam ĝi ne permesas, la supra kapta metodo ankoraŭ funkcias kaj postulas nenion krom gastiganto, kiun vi jam kontrolas.
Elektu riparon, kiu kongruas kun la paneo
Se la paneanta funkcio estas samranga, la subtenataj respondoj estas relajso, renkontiĝa servo, kiun ambaŭ samranguloj povas atingi, aŭ alia topologio. TURN ekzistas ĝuste por tio, kaj produkto, kiu liveras sian propran relajson, diras al vi, ke ĝi atendas kelkajn retojn malamikaj.
Se la paneanta funkcio estas ordinara tunelo, la konduto de la mapado ne estas via problemo kaj nenio el la supra validas. Kontrolu, ke la kliento vere sendas, ke la servilo vidas la paketon kaj ke la respondo revenas. Tiu sinsekvo estas tri observoj kaj ĝi postulas neniom da scio pri la NAT-kategorio de la enkursigilo.
Kio ne funkcias, estas disŝuti lokajn pordajn ŝanĝojn ĝis io konektiĝas. Ŝanĝi la fontan pordon de la kliento ne ŝanĝas, kiel la reto atribuas mapadojn. Hazarda sukceso ĉe la kvina provo estas falsa pozitivo, kaj ĝi estos citata kiel solvo dum monatoj.
Registru la arkitekturon, ne la verdikton
Utila noto diras, kiu protokolo, en kiu direkto la sesio komenciĝas, ĉu relajso estas en la vojo, kaj kio estis observita sur la drato. „simetria NAT, ne funkcias” estas neuzebla, ĉar ĝi samtempe malĝustas pri la tunelo kaj neinformas pri la vojo de la samrangulo.
Inkluzivu la mezuritan pordan stabilecon kaj la filtradan konduton, se vi testis ilin. Tiuj du faktoj ebligas al iu alia antaŭdiri, ĉu nova funkcio funkcios en tiu reto sen ripeti la tutan esploradon. Ili ankaŭ maljuniĝas pli bone ol vendista kategorio, kiu signifas ion iomete alian sur ĉiu helppaĝo.
Fine, tenu la terminologion de RFC 4787 preta, kiam vi skribos tion. Uzi la precizajn terminojn kostas unu frazon kaj malhelpas la sekvan leganton ripeti la saman misdiagnozon, kaj tio estas la tuta senco de skribi la noton.