Nebula punchy beállítások: melyik javítja meg a NAT-ot

Két peer a világítótoronyon keresztül megtalálja egymást, majd nem tud közvetlen útvonalat építeni, és az első ösztön minden punchy opció bekapcsolása. Ez az ösztön három változtatású konfigurációt hoz létre, és fogalma sincs, melyik számított. A beállítások különböző kérdésekre válaszolnak: az egyik egy már létező leképezést tart fenn, a másik pedig fordított irányban kísérel meg kézfogást. Döntse el, melyik kérdése van, mielőtt bármelyikhez hozzányúl.

Előbb a végpontot, aztán az időzítést

Egy peer, amely soha nem jelenik meg a várt címen, nem menekül meg a punch hangolásától. Ellenőrizze, mit tud a világítótorony a peer-ről, és mit hirdet a peer saját konfigurációja, mert egy elavult bootstrap-cím vagy egy tévedésből közzétett magáncím minden átjárási trükköt meghiúsít. Azt is erősítse meg, hogy a tanúsítvány megbízható, mert a nem megbízható identitás jóval azelőtt leállítja a beszélgetést, hogy a NAT számítana. Utána ellenőrizze, hogy az UDP egyáltalán eléri-e a világítótornyot. Az időértékeket kell utoljára megnézni, nem elsőként.

Jegyezze fel a végpontpárt, amellyel tesztel, hogy a későbbi összehasonlítások ugyanazokat a peer-eket használják, ne két másik gépet.

A punch leképezést tart, a respond irányt nyit

A punch opció rendszeresen üres csomagokat küld egy már alagúttal rendelkező peer alapszintű címére. A célja nem fényes: megakadályozza, hogy egy állapotkövető NAT vagy tűzfal lejárja azt a leképezést, amelytől a közvetlen útvonal függ. A respond opció megváltoztatja, mi történik egy világítótorony-értesítésnél, és ráveszi a gazdagépet, hogy kézfogással próbálkozzon visszafelé a peer felé, amely el akarja érni. Ezek különböző mechanizmusok, különböző hibamódokkal.

Válassza a punch opciót, ha a közvetlen útvonal működik, majd később gyengül. Válassza a respond opciót, ha az útvonal soha nem alakul ki egy irányban. Mindkettőt bekapcsolni és reménykedni az a mód, ahogy egy ötperces javítás egyhetes hangolássá válik.

A késleltetések azt döntik el, mikor, nem azt, hogy

A késleltetési értékek eltolják az időzítést: az egyik az értesítés után küldött csomagra vonatkozik, a másik a fordított kézfogási kísérletre. Egyik sem tesz működőképessé egy blokkolt irányt. Mindkettő egyszerre történő módosítása tönkreteszi az összehasonlítást, amelyet épp el akart végezni.

Hagyja őket békén, amíg a mechanizmus nem lesz megfelelő. Utána állítson be egyet, és írja fel a régi értéket.

Amikor a relay a tisztességes válasz

Néhány NAT-kombináció nem tud közvetlen útvonalat támogatni, akárhogyan is rendezik az időzítést. A kétoldali szimmetrikus NAT, vagy egy tűzfal, amely teljesen eldobja a kéretlen bejövő forgalmat, nem hagy semmit átlyukasztani.

Az elérhető címmel rendelkező relay-csomópont olyan útvonalat ad ezeknek a peer-eknek, amely nem függ az átjárás sikerétől. Sávszélességbe kerül azon a csomóponton keresztül, tehát kapacitásról szóló döntés, nem kerülőút. Konfigurálja a relayt szándékosan és ellenőrizze, hogy a peer-ek el tudják érni, mert egy maga is nehéz NAT mögött álló relay semmin nem változtat. Utána hagyja abba a punch beállításainak hangolását arra a párra, mert a közvetlen útvonal soha nem fog megjelenni.

A kudarcot vallott párt tétlenség után tesztelje

Reprodukálja a megtört feltételt: hagyja a párt ugyanannyi ideig tétlenül, vagy ismételje meg a korábban sikertelen kézfogás-sorozatot. Utána gyakorolja az alkalmazást a két peer között, ne egy kérést a világítótoronyhoz. A világítótorony válasza a vezérlőútvonalat bizonyítja, és semmit sem mond az adatútvonalról.

Jegyezze fel, melyik beállítás változott, az időpontot, és hogy megjelent-e közvetlen útvonal vagy a forgalom a relayen maradt. Ha maradt, a válasz egy relay és egy kapacitásmegjegyzés, és ez teljesen jó eredmény. Ha megjelent, a következő kérdés, hogy kibír-e egy óra tétlenséget, mert a gyengülő leképezés pontosan az a probléma, amelyre a punch létezik.