Nastavení punchy v Nebule: které opraví vaše NAT

Dva peerové se najdou přes maják a pak nedokážou postavit přímou cestu, a první instinkt je zapnout každou volbu punchy. Ten instinkt vytvoří konfiguraci se třemi změnami a bez představy, která z nich byla důležitá. Nastavení odpovídají na různé otázky: jedno udržuje mapování, které už existuje, a druhé zkouší handshake v opačném směru. Rozhodněte, kterou otázku máte, než se dotknete kterékoli z nich.

Ověřte koncový bod dřív než časování

Peer, který se nikdy neobjeví na očekávané adrese, nebude zachráněn laděním punch. Zkontrolujte, co maják o peerovi ví a co ohlašuje jeho vlastní konfigurace, protože zastaralá bootstrap adresa nebo soukromá adresa publikovaná omylem zmaří každý trik průchodu. Ověřte také, že certifikát je důvěryhodný, protože nedůvěryhodná identita zastaví konverzaci dávno předtím, než začne záležet na NAT. Potom ověřte, zda se UDP vůbec dostane k majáku. Časové hodnoty jsou poslední, na co se dívat, ne první.

Zapište si pár koncových bodů, se kterým testujete, aby pozdější srovnání používala stejné peery a ne dva jiné stroje.

punch drží mapování, respond otevírá směr

Volba punch pravidelně posílá prázdné pakety na adresu spodní vrstvy peera, který už má tunel. Její účel není efektní: brání stavovému NAT nebo firewallu, aby nechal vypršet mapování, na kterém přímá cesta závisí. Volba respond mění, co se stane při oznámení z majáku, a nutí hostitele zkusit handshake zpět k peerovi, který se ho snaží dosáhnout. To jsou různé mechanismy s různými režimy selhání.

Zvolte punch, když přímá cesta funguje a později slábne. Zvolte respond, když se cesta v jednom směru nikdy nevytvoří. Zapnout obojí a doufat je způsob, jak se z pětiminutové opravy stane týden ladění.

Zpoždění rozhodují kdy, ne zda

Hodnoty zpoždění posouvají časování: jedna platí pro paket odeslaný po oznámení, druhá pro pokus o obrácený handshake. Ani jedna nezpůsobí, že zablokovaný směr bude fungovat. Změna obou najednou zničí srovnání, které jste se chystali provést.

Nechte je být, dokud nebude mechanismus správný. Pak upravte jeden a zapište si starou hodnotu.

Když je relé poctivá odpověď

Některé kombinace NAT nemohou podporovat přímou cestu, ať je časování uspořádáno jakkoli. Symetrický NAT na obou stranách nebo firewall, který zcela zahazuje nevyžádaný příchozí provoz, nenechají nic k proražení.

Reléový uzel s dosažitelnou adresou dává těmto peerům cestu, která nezávisí na úspěchu průchodu. Spotřebovává šířku pásma přes ten uzel, takže je to rozhodnutí o kapacitě, ne obejití. Nakonfigurujte relé záměrně a zkontrolujte, že se k němu peerové dostanou, protože relé, které je samo za obtížným NAT, nic nezmění. Pak přestaňte ladit punch pro ten pár, protože přímá cesta se nikdy neměla objevit.

Otestujte pár, který selhal, po nečinnosti

Zopakujte podmínku, která se rozbila: nechte pár nečinný stejný interval, nebo zopakujte sekvenci handshake, která dřív selhávala. Pak procvičte aplikaci mezi těmito dvěma peery, ne požadavek na maják. Odpověď majáku dokazuje řídicí cestu a nic o datové cestě.

Zapište, které nastavení se změnilo, čas a zda se objevila přímá cesta nebo provoz zůstal na relé. Pokud zůstal, odpovědí je relé a poznámka o kapacitě, a to je naprosto dobrý výsledek. Pokud se objevila, další otázkou je, zda přežije hodinu nečinnosti, protože mapování, které vyprchá, je přesně problém, kvůli kterému punch existuje.