Protokół 47 kontra port TCP 47: dwa nagłówki, dwie reguły

Sieci hotelowe i zapory konferencyjne często pokazują własne pole zezwolenia, a ktoś wpisuje w nie 47, licząc na to, że PPTP zadziała. Reguła powstaje, tunel nadal zawodzi, a kolejna próba używa innego numeru. Błąd tkwi w samym pakiecie: IPv4 ma pole protokołu, które nazywa to, co następuje po nagłówku IP, natomiast TCP i UDP mają pola portu, które istnieją tylko wtedy, gdy jesteś wewnątrz jednego z tych nagłówków. To nie są dwa zapisy tego samego zezwolenia.

Nagłówek IPv4 nazywa następny protokół

Pole protokołu to jeden bajt w nagłówku IPv4 i zawiera numer opisujący ładunek: 6 dla TCP, 17 dla UDP, 47 dla GRE, 50 dla ESP. Wszystko, co filtruje pakiety, czyta tę wartość, zanim spojrzy głębiej, ponieważ głębszy nagłówek ma sens dopiero po poznaniu typu. Zmień później port w rozmowie, a to pole się nie przesunęło.

Reguła napisana przeciw protokołowi 47 opisuje więc warstwę IP. Żaden port nie bierze udziału w decyzji.

Porty istnieją wewnątrz TCP i UDP, nigdzie indziej

Porty to szesnastobitowe identyfikatory wewnątrz nagłówków TCP i UDP, a ich zadaniem jest rozdzielanie rozmów dzielących jeden adres. Nagłówek GRE niesie wartość typu protokołu, często EtherType, oraz opcjonalne klucze do multipleksowania. Dlatego wyrażenie port 47 nie nazywa niczego, z czym pakiet GRE mógłby się zgodzić.

Interfejsy zapór różnią się tym, ile z tego pokazują. Niektóre przyjmują numer protokołu, inne oferują nazwaną listę, a kilka przyjmuje tylko TCP lub UDP z portami.

PPTP używa obu warstw jednocześnie

PPTP jest najjaśniejszym przykładem, bo celowo dzieli swoją pracę między obie warstwy. Połączenie sterujące to sesja TCP do portu 1723, a ścieżka danych to GRE, protokół 47, bez żadnego portu gdziekolwiek. Zapora, która zezwala na 1723 i nic więcej, pozwala negocjacjom się rozpocząć, a potem odrzuca ładunek. Tunel wygląda, jakby zawieszał się po uwierzytelnieniu, zamiast nie łączyć, i dlatego objaw jest często zgłaszany jako problem z hasłem.

Czytaj oba wiersze osobno, pisząc regułę, i sprawdzaj każdy z nich wobec składni dostawcy. Jeden wiersz potrzebuje portu, drugi numeru protokołu, i żaden pojedynczy wpis nie obejmuje obu.

Dlaczego strona przekierowania portów nie potrafi wyrazić GRE

Formularz przekierowania, który przyjmuje tylko TCP i UDP, nie potrafi opisać GRE, jakkolwiek by się nazywał. Tłumaczenie adresów dodaje drugą trudność, bo GRE nie ma portów, a translator musi zamiast tego śledzić identyfikator wywołania. Niektóre routery domowe mają pomocnika, który to obsługuje; wiele nie, i żaden dodatkowy wpis zezwolenia TCP nie stworzy takiego zachowania.

Gdy prawdziwym wymaganiem jest nowoczesny tunel, wybierz projekt, który świadomie używa TCP albo UDP, zamiast liczyć na to, że translator zgadnie poprawnie.

Enkapsulacja decyduje, co widzi filtr

Enkapsulacja zmienia zewnętrzny pakiet, a zewnętrzny pakiet jest tym, z czym zgadza się reguła. Natywny ESP to protokół 50, podczas gdy przejście przez NAT owija ESP w UDP 4500, aby przetrwało tłumaczenie adresów. Filtr, który zezwala na UDP 4500, nigdy nie widzi protokołu 50, a filtr napisany dla protokołu 50 nigdy nie pasuje do owiniętej formy.

Zapytaj, co do enkapsulacji uzgodnili klient i brama, a potem napisz regułę dokładnie dla tej zewnętrznej formy i nic więcej.

Napisz regułę tak, żeby ktoś mógł ją sprawdzić

Wyraź każdą regułę jako rodzinę adresów, zewnętrzny protokół, porty transportowe, jeśli są, kierunek i oba końce. Recenzent może porównać to zdanie ze zrzutem pakietów i wydać osąd. Polecenia otwarcia 47 nikt nie może sprawdzić, i dlatego przetrwa ono w instrukcjach przez lata.

Dodaj test, który to udowadnia: połącz się, przechwytując pakiety na zewnętrznym interfejsie, i potwierdź zewnętrzny protokół oraz port, które naprawdę pojawiają się w śladzie.