Nebula punchy nustatymai: kuris sutvarko jūsų NAT

Du peerai randa vienas kitą per švyturį, o paskui nesugeba nutiesti tiesioginio kelio, ir pirmas instinktas yra įjungti kiekvieną punchy parinktį. Tas instinktas sukuria konfigūraciją su trimis pakeitimais ir be supratimo, kuris iš jų buvo svarbus. Nustatymai atsako į skirtingus klausimus: vienas palaiko jau egzistuojantį susiejimą, o kitas bando rankos paspaudimą priešinga kryptimi. Nuspręskite, kurį klausimą turite, prieš liesdami bet kurį iš jų.

Pirmiausia patikrinkite galinį tašką, paskui laiką

Peer, kuris niekada nepasirodo laukiamu adresu, nebus išgelbėtas punch derinimo. Patikrinkite, ką švyturys žino apie peerą ir ką skelbia jo paties konfigūracija, nes pasenęs bootstrap adresas arba per klaidą paskelbtas privatus adresas sužlugdo bet kokį perėjimo triuką. Taip pat patvirtinkite, kad sertifikatas yra patikimas, nes nepatikima tapatybė sustabdo pokalbį gerokai anksčiau, nei NAT tampa svarbus. Tada patikrinkite, ar UDP apskritai pasiekia švyturį. Laiko reikšmės yra paskutinis dalykas, į kurį reikia žiūrėti, o ne pirmas.

Užsirašykite galinių taškų porą, su kuria bandote, kad vėlesni palyginimai naudotų tuos pačius peerus, o ne dvi kitas mašinas.

punch išlaiko susiejimą, respond atveria kryptį

punch parinktis periodiškai siunčia tuščius paketus į peero, kuris jau turi tunelį, apatinio sluoksnio adresą. Jos tikslas neįspūdingas: ji neleidžia būsenos turinčiam NAT ar ugniasienei leisti pasibaigti susiejimui, nuo kurio priklauso tiesioginis kelias. respond parinktis keičia tai, kas vyksta gavus švyturio pranešimą, ir priverčia hostą bandyti rankos paspaudimą atgal link peero, kuris bando jį pasiekti. Tai skirtingi mechanizmai su skirtingais gedimo režimais.

Rinkitės punch, kai tiesioginis kelias veikia ir vėliau silpnėja. Rinkitės respond, kai kelias niekada nesusiformuoja viena kryptimi. Įjungti abu ir tikėtis yra būdas, kaip penkių minučių pataisymas tampa savaitės derinimu.

Delsos nusprendžia kada, o ne ar

Delsos reikšmės pastumia laiką: viena taikoma paketui, siunčiamam po pranešimo, kita atvirkštinio rankos paspaudimo bandymui. Nė viena nepadaro užblokuotos krypties veikiančios. Keisti abi iš karto sugriauna palyginimą, kurį ruošėtės atlikti.

Palikite juos ramybėje, kol mechanizmas bus teisingas. Tada pakoreguokite vieną ir užsirašykite seną reikšmę.

Kai relė yra sąžiningas atsakymas

Kai kurie NAT deriniai negali palaikyti tiesioginio kelio, kad ir kaip būtų išdėstytas laikas. Simetrinis NAT abiejose pusėse arba ugniasienė, kuri visiškai atmeta neprašytą įeinančią eismą, nepalieka nieko pradurti.

Relės mazgas su pasiekiamu adresu duoda tiems peerams kelią, kuris nepriklauso nuo perėjimo sėkmės. Tai kainuoja pralaidumą per tą mazgą, todėl tai sprendimas apie talpą, o ne apėjimas. Sąmoningai sukonfigūruokite relę ir patikrinkite, ar peerai gali ją pasiekti, nes relė, kuri pati yra už sudėtingo NAT, nieko nekeičia. Tada nustokite derinti punch nustatymus tai porai, nes tiesioginis kelias niekada neturėjo atsirasti.

Išbandykite nepavykusią porą po prastovos

Atkurkite sąlygą, kuri sugedo: palikite porą nenaudojamą tą patį intervalą arba pakartokite rankos paspaudimų seką, kuri anksčiau nepavykdavo. Tada išbandykite programą tarp tų dviejų peerų, o ne užklausą švyturiui. Švyturio atsakymas įrodo valdymo kelią ir nieko apie duomenų kelią.

Užsirašykite, kuris nustatymas pasikeitė, laiką ir ar atsirado tiesioginis kelias, ar eismas liko relėje. Jei liko, atsakymas yra relė ir talpos pastaba, ir tai visiškai geras rezultatas. Jei atsirado, kitas klausimas, ar jis atlaiko valandą prastovos, nes silpstantis susiejimas yra būtent ta problema, kuriai punch egzistuoja.