Przekazywać wszystko do jednego hosta czy przepisywać też port?

Przekazywanie wszystkiego do serwera VPN może opisywać dwie bardzo różne reguły. Jedna zmienia adres docelowy i zachowuje port przychodzący; druga przepisuje też port na jednego odbiorcę. Ekspozycja nie jest taka sama, a decyzja zależy od trzech warunków, nie od etykiety używanej przez interfejs routera.

Pierwszy warunek: które pola zmienia reguła?

Tłumaczenie adresu docelowego i tłumaczenie portu docelowego to osobne operacje. Reguła może wykonać tylko pierwszą albo obie razem, a różnica decyduje, które usługi na hoście docelowym są osiągalne. Większość interfejsów producentów ukrywa ten wybór za jedną etykietą. Odczytanie samej reguły to jedyny sposób, by wiedzieć, którą otrzymałeś.

Czytaj rzeczywistą regułę, a nie etykietę menu. Ekran, na którym jest DMZ lub wszystkie porty, opisuje zamiar, a nie ścieżkę pakietu. Dokumentacja Netfilter NAT rozdziela oba tłumaczenia i to jest właściwy model myślowy, nawet gdy router przed tobą jest urządzeniem konsumenckim.

Dwa pola, dwa różne pytania.

Drugi warunek: co nasłuchuje na zachowanych portach?

Jeśli reguła zachowuje port przychodzący, każdy przychodzący port jest dostarczany na ten sam numer na hoście VPN, zależnie od polityki wejściowej tego hosta. Obejmuje to usługi, o których być może zapomniałeś, że nasłuchują. Reguła nie stworzyła tych usług i teraz jest do nich drogą.

Jeśli reguła przepisuje port, dzieje się odwrotnie: wiele portów zewnętrznych zapada się na jednego odbiorcę i nic innego na hoście nie jest osiągalne przez tę regułę. Przepisanie na stały port nie staje się dostępem do każdej usługi lokalnej tylko dlatego, że pasował do niego szeroki zakres portów zewnętrznych. Oba projekty zawodzą w różnych kierunkach, a tryb awarii jest tym, co wybierasz. Wybierz ten, którego awarię możesz zaakceptować.

Zinwentaryzuj odbiorcę, zanim wybierzesz.

Trzeci warunek: jak szerokie jest wejście zewnętrzne?

Publikowanie jednego wybranego portu jest węższe niż publikowanie zakresu, a oba są węższe niż akceptowanie wszystkiego. Szerokość zewnętrzna i tłumaczenie wewnętrzne to niezależne wybory, a większość zamieszania bierze się ze zmieniania jednego przy opisywaniu drugiego.

Dla zwykłego wejścia VPN opublikuj transport i odbiorcę, których projekt naprawdę potrzebuje. Następnie przejrzyj trzy kolejne rzeczy: efektywne mapowanie routera, własne reguły wejściowe hosta docelowego i to, czy odbiorca IPv6 publikuje tę samą usługę. Reguła, która wygląda wąsko w jednej rodzinie adresów, może być szeroka w drugiej.

Zapisz przetłumaczony punkt końcowy w całości: protokół, port zewnętrzny, adres wewnętrzny, port wewnętrzny.

Czego nie daje ci żadna z tych reguł

Żaden z obu projektów nie dowodzi, że usługa jest wolna od luk, i żaden nie chroni dostępności. Uwierzytelnianie, aktualizacje i odzyskiwanie pozostają w zakresie niezależnie od tego, jak wąskie jest mapowanie portów. Wąskie mapowanie zmniejsza osiągalną powierzchnię; nie czyni odbiorcy bezpiecznym.

Szeroka reguła, która już obsługuje inną legalną usługę, jest zależnością, a nie tylko błędem. Zinwentaryzuj ją i zastąp przez jej właściciela, zanim ją usuniesz, inaczej zmiana będzie wyglądać jak awaria spowodowana poprawką bezpieczeństwa. Ta sama ostrożność dotyczy przepisania na stały port, na którym coś innego po cichu polega.

Analiza ekspozycji dotyczy tego, co może dotrzeć do czego, a nie etykiety na ekranie.

Zdecyduj z przetłumaczonym punktem końcowym w ręku

Zapisz wynik reguły jako zdanie: publiczny port UDP X dociera do adresu Y port Z. Następnie zapytaj, które usługi na Y mogą odpowiedzieć na Z i do kogo należą.

nft list ruleset

Jeśli odpowiedzią jest ten jeden odbiorca, którego zamierzałeś, reguła robi swoje.

Jeśli odpowiedzią jest kilka, wybrałeś przekazywanie na całego hosta, niezależnie od tego, czy interfejs tak to nazwał.