Ustawienia punchy w Nebuli: które naprawia twój NAT

Dwa peery odnajdują się przez latarnię, a potem nie potrafią zbudować bezpośredniej ścieżki, i pierwszy odruch to włączenie każdej opcji punchy. Ten odruch daje konfigurację z trzema zmianami i bez pojęcia, która z nich miała znaczenie. Ustawienia odpowiadają na różne pytania: jedno utrzymuje mapowanie, które już istnieje, a drugie próbuje uścisku dłoni w przeciwnym kierunku. Zdecyduj, które pytanie masz, zanim dotkniesz któregokolwiek z nich.

Potwierdź punkt końcowy przed czasem

Peer, który nigdy nie pojawia się pod oczekiwanym adresem, nie zostanie uratowany przez strojenie punch. Sprawdź, co latarnia wie o peerze i co ogłasza jego własna konfiguracja, bo nieaktualny adres bootstrap albo adres prywatny opublikowany przez pomyłkę niweczy każdy trik przechodzenia. Potwierdź też, że certyfikat jest zaufany, ponieważ niezaufana tożsamość zatrzymuje rozmowę na długo przed tym, zanim NAT zacznie mieć znaczenie. Potem sprawdź, czy UDP w ogóle dociera do latarni. Wartości czasu to ostatnia rzecz, na którą się patrzy, a nie pierwsza.

Zapisz parę punktów końcowych, z którą testujesz, żeby późniejsze porównania używały tych samych peerów, a nie dwóch innych maszyn.

punch zachowuje mapowanie, respond otwiera kierunek

Opcja punch okresowo wysyła puste pakiety na adres warstwy niższej peera, który ma już tunel. Jej cel nie jest efektowny: nie pozwala NAT-owi stanowemu ani zaporze ogniowej wygasnąć mapowania, od którego zależy bezpośrednia ścieżka. Opcja respond zmienia to, co dzieje się przy powiadomieniu latarni, każąc hostowi próbować uścisku dłoni z powrotem w stronę peera, który próbuje go osiągnąć. To różne mechanizmy z różnymi trybami awarii.

Wybierz punch, gdy bezpośrednia ścieżka działa, a potem słabnie. Wybierz respond, gdy ścieżka nigdy nie powstaje w jednym kierunku. Włączanie obu i nadzieja to sposób, w jaki pięciominutowa poprawka staje się tygodniem strojenia.

Opóźnienia decydują kiedy, nie czy

Wartości opóźnień przesuwają czas: jedna dotyczy pakietu wysyłanego po powiadomieniu, druga próby odwrotnego uścisku dłoni. Żadna nie sprawia, że zablokowany kierunek działa. Zmiana obu naraz niszczy porównanie, które mieliście wykonać.

Zostaw je w spokoju, dopóki mechanizm nie będzie właściwy. Potem dostrój jedną i zapisz starą wartość.

Kiedy przekaźnik jest uczciwą odpowiedzią

Niektóre kombinacje NAT nie potrafią obsłużyć bezpośredniej ścieżki, niezależnie od ułożenia czasu. Symetryczny NAT po obu stronach albo zapora ogniowa, która całkowicie odrzuca nieproszony ruch przychodzący, nie zostawiają niczego do przebicia.

Węzeł przekaźnika z osiągalnym adresem daje tym peerom ścieżkę, która nie zależy od powodzenia przechodzenia. Kosztuje to pasmo przez ten węzeł, więc jest decyzją o przepustowości, a nie obejściem. Skonfiguruj przekaźnik świadomie i sprawdź, czy peery mogą go osiągnąć, bo przekaźnik, który sam stoi za trudnym NAT-em, niczego nie zmienia. Potem przestań stroić ustawienia punch dla tej pary, bo bezpośrednia ścieżka nigdy nie miała się pojawić.

Przetestuj parę, która zawiodła, po bezczynności

Odtwórz warunek, który się zepsuł: zostaw parę bezczynną przez ten sam interwał albo powtórz sekwencję uścisków dłoni, która wcześniej zawodziła. Potem przećwicz aplikację między tymi dwoma peerami, a nie żądanie do latarni. Odpowiedź latarni dowodzi ścieżki sterowania i niczego o ścieżce danych.

Zapisz, które ustawienie się zmieniło, czas i czy pojawiła się bezpośrednia ścieżka, czy ruch pozostał na przekaźniku. Jeśli pozostał, odpowiedzią jest przekaźnik i notatka o przepustowości, i to zupełnie dobry wynik. Jeśli się pojawiła, kolejne pytanie brzmi, czy przetrwa godzinę bezczynności, bo wygasające mapowanie to dokładnie ten problem, dla którego istnieje punch.