Jump to content

bluzman

Użytkownicy
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

0 Neutral

About bluzman

  • Rank
    Młodszy Użytkownik
  1. Pakiet do translacji iptables>nftables mam od początku. Już przerabiałem te linki wcześniej, ładnie opisane ale nic nie rozwiązuje. Powyższy przykład na wiki w zasadzie niczego nie wprowadza przydatnego jak dla mnie. Tu zrobili taką strukturę, że są łańcuchy dla ipv4 i dla ipv6 w tablicy inet a vmap: # Allow traffic from established and related packets, drop invalid ct state vmap { established : accept, related : accept, invalid : drop } # Allow loopback traffic. iifname lo accept # Jump to chain according to layer 3 protocol using a verdict map meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 } odsyła do nich U mnie dokładnie to tak wygląda, tyle że ipv6 nie używane jest table ip filter { chain input { type filter hook input priority filter; policy drop; iifname "lo" counter packets 202 bytes 658758 accept ct state established,related counter packets 37308 bytes 8916821 accept tcp dport 22 counter packets 1609 bytes 254971 accept udp dport 53 ct state established counter packets 0 bytes 0 accept tcp dport 53 ct state established counter packets 0 bytes 0 accept udp sport 53 ct state established counter packets 0 bytes 0 accept tcp sport 53 ct state established counter packets 0 bytes 0 accept udp dport 51820 ct state new counter packets 2 bytes 352 accept } chain output { type filter hook output priority filter; policy accept; udp sport 53 ct state established counter packets 1150 bytes 159030 accept tcp sport 53 ct state established counter packets 21 bytes 1220 accept udp dport 53 ct state established counter packets 0 bytes 0 accept tcp dport 53 ct state established counter packets 159 bytes 6651 accept } chain forward { type filter hook forward priority filter; policy accept; ct state established,related counter packets 5084 bytes 2919832 accept iifname "wg0" oifname "wg0" ct state new counter packets 0 bytes 0 accept } } table ip nat { chain prerouting { type nat hook prerouting priority dstnat; policy accept; } chain postrouting { type nat hook postrouting priority srcnat; policy accept; oifname "eth0" ip saddr 10.200.200.0/24 counter packets 341 bytes 36726 masquerade } }
  2. Zasadniczo to tak, chyba transferowania stref używa się przy serwerach autorytatywnych? Chwilowo to mam ten w/w problem z nftables i wcale nie keszuje się DNS.
  3. Przestawiam się z iptables na nftables i coś tu nie wychodzi do końca z blokowaniem całej polityki łańcucha input, czyli w iptables to by wyglądało tak: iptables -A INPUT -j DROP a w nftables na końcu łańcucha table ip filter { chain input { type filter hook input priority filter; policy accept; iifname "lo" counter packets 264 bytes 863192 accept ct state established,related counter packets 41894 bytes 9758780 accept tcp dport 22 counter packets 1719 bytes 268543 accept udp dport 53 ct state established counter packets 0 bytes 0 accept tcp dport 53 ct state established counter packets 0 bytes 0 accept udp sport 53 ct state established counter packets 0 bytes 0 accept tcp sport 53 ct state established counter packets 0 bytes 0 accept udp dport 51820 ct state new counter packets 3 bytes 528 accept counter packets 1 bytes 141 drop } Po dodaniu powyższej reguły niby działa, ALE Unbound nie keszuje adresów wcale. W czym problem? W tej zaporze jakoś inaczej się blokuje się wszystkie porty? Jeszcze jeden problem jest z łańcuchami. Kiedy dodaję do wszystkiego łańcuch z "policy drop' table ip filter { chain blokowane { type filter hook input priority filter; policy drop; } blokuje mnie, wywala z połączenia i muszę robić reboot serwera z pulpitu VPS a co mnie dziwi jeszcze bardziej to, że przy dopisywaniu tego łańcucha nftables jest wyłączony i zastopowany, czyli: systemctl disable nftables systemctl stop nftables
  4. Czy w unbound można 2 razy wpisać do konfiguracji opcję "interface:" ? Jedno z IP publicznym i drugie z lokalnym serwera. Mam router porypany, który nie rozumie swojego publicznego IP od sieci lokalnej. Komputery z jego lokalnej mogą do serwera się dostać do usług różnych wpisując adres wewnętrzny serwera192.168.0.X a serwer można jedynie w funkcji DMZ umieścić, żeby wystawić go przed router.
  5. Skoro już jesteśmy przy temacie DNS oraz iptables to zadam pytania, żeby nie rozciągać tego na kolejne posty. Plan jest taki, że ostatecznie ta konfiguracja wyląduje na lokalnej maszynie gdzie jest słabe łącze internetowe (ewentualnie na tym VPS jeszcze podziała). Chciałbym dodać do tego kolejny forward-zone dla szyfrowania TLS na porcie 853. Rozumiem, że należałoby dodać port 853 analogicznie do iptables jak teraz ten 53? Następne pytanie to utrzymanie tego keszu. Nie mam doświadczenia w tym. Jak zrobię restart serwera to cała zawartość zostanie skasowana, czy należałoby napisać jakiś skrypt w bashu i dodać np. do crona żeby zapisywał do pliku i później przywracać zawartość po restarcie? No i te te adresy też mają jakąś żywotność ustawioną. Czy jest sens robienia tego wszystkiego, zbierać wpisy w pamięci jeżeli to się kasuje a komputery w sieci lokalnej nie działają np. 1-2 dni? Załączę jeszcze plik konfiguracyjny unbound żeby pokazać wszystko a głównie czasy żywotności i ilość pamięci. unbound.conf
  6. Oczywiście, że nie. Głupotę walnąłem. Byłem przekonany, że jest. To trudno trochę zauważyć po komendzie "iptables -L". Otworzyłem plik z zapisanymi regułami iptables to zobaczyłem, że nie ma ruchu lo. Musiałem nie zapisać i po restarcie firewalla zniknął. To tak na przyszłość będzie dla potrzebujących konfiguracji dla DNS informacja. Trzeba mieć: iptables -I INPUT 1 -i lo -j ACCEPT Teraz jest: [[email protected] ~]# unbound-control status version: 1.13.2 verbosity: 1 threads: 4 modules: 3 [ ipsecmod validator iterator ] uptime: 93399 seconds options: reuseport control unbound (pid 23368) is running... Dziękuję za pomoc.
  7. Wstawiłem te regułki ale nie działa. btw. iptables wypluwa błąd o "--dport" iptables -A INPUT -p all --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables v1.8.7 (legacy): unknown option "--dport" Try `iptables -h' or 'iptables --help' for more information. Kiedy zmieniłem parametr "-p all" na "-p udp" i "-p tcp" i oddzielnie wstawiam, jedno po drugim to jest dobrze. Chyba ta wersja iptables nie rozumie "all" Podaję moją konfigurację obecną po wstawieniu w/w regułek Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 2 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh 3 ACCEPT tcp -- anywhere anywhere tcp dpt:http 4 ACCEPT udp -- anywhere anywhere udp dpt:domain ctstate NEW,ESTABLISHED 5 ACCEPT tcp -- anywhere anywhere tcp dpt:domain ctstate NEW,ESTABLISHED 6 ACCEPT udp -- anywhere anywhere udp spt:domain ctstate ESTABLISHED 7 ACCEPT tcp -- anywhere anywhere tcp spt:domain ctstate ESTABLISHED 8 ACCEPT udp -- anywhere anywhere udp dpt:51820 ctstate NEW 9 DROP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 2 ACCEPT all -- anywhere anywhere ctstate NEW Chain OUTPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT udp -- anywhere anywhere udp spt:domain ctstate ESTABLISHED 2 ACCEPT tcp -- anywhere anywhere tcp spt:domain ctstate ESTABLISHED 3 ACCEPT udp -- anywhere anywhere udp dpt:domain ctstate NEW,ESTABLISHED 4 ACCEPT tcp -- anywhere anywhere tcp dpt:domain ctstate NEW,ESTABLISHED [[email protected] ~]# unbound-control status [1635325847] unbound-control[29009:0] fatal error: timeout: could not connect to server
  8. Wiem, robiłem regułki dla udp i tcp oraz jedno i drugie. To co napisałem to tylko przykłady, trochę nie precyzyjnie opisałem.
  9. Witam. Postanowiłem skonfigurować DNS typu cache na zewnętrznej maszynie (VPS) używając Unbound. Sama konfiguracja usługi raczej jest poprawna. Po sprawdzeniu "unbound-checkconf" nie wypluwa żadnych błędów. Problem tkwi w iptables. Bez firewalla serwer działa, keszuje, wszystko ok, jak go włączę to przy sprawdzaniu przez "unbound-control status" pokazuje błąd z połączeniem "unbound-control[23452:0] fatal error: timeout: could not connect to server". W sieci są poradniki do konfigurowania DNS, wiele przetestowałem i nic to nie dało. Zaczynając od najprostszych reguł "iptables -A INPUT -p tcp –dport 53 -j ACCEPT" i "iptables -A OUTPUT -p tcp –dport 53 -j ACCEPT" kończąc na tych bardziej zaawansowanych. Zwracam się o pomoc w konfiguracji iptables, jak to ma wyglądać bo już nie mam pomysłów a jest to pierwszy DNS jaki postawiłem.
  10. Wcześniejsze polecenia z tego linku, strony redhata już zastosowałem wcześniej. Teraz zastosowałem 2 w/w nft add rulmasqueradee ip nat postrouting oifname "eth0" lub nft add rulmasqueradee nat postrouting oifname "eth0" Nic nie działa niestety. Mam wrażenie czy jest tu 'ip' w składni polecenia czy nie to na jedno wychodzi. Może wcześniej było inaczej ale np. jak się tworzy tabelę to czy wpiszę "nft add table ip filter" czy "nft add table filter" to i tak w pliku z konfiguracją powstaje tabela opisana "table ip filter {....}". Nie tak jak w plikach domyślnych po instalacji nftables w katalogu /etc/nftables/ np. ipv4-mangle.nft, ipv4-filter.nft jest table mangle {...} itd. W każdym razie wracam do punktu wyjścia.
  11. Tzn. wystarczy coś takiego? nft add rule ip nat postrouting oifname "eth0" masquerade
  12. Zacząłem poznawać Fedorę na tanim vps i wirtualce. Używam do VPN Wireguarda, zaczynam tłumaczyć reguły, poprawiać itd. W jednym mam problem. Jest taka regułka dla iptables dotycząca tego VPNa: iptables -t nat -A POSTROUTING -s 10.200.200.0/24 -o eth0 -j MASQUERADE po przetłumaczeniu narzędziem iptables-translate wychodzi nft add rule ip nat postrouting oifname "eth0" ip saddr 10.200.200.0/24 counter masquerade Przykład tego w tym tutku można zobaczyć, dobry przykład PRZYKŁAD - punkt 6 Ja niby nie widzę błędu, przeanalizowałem składnie. U mnie całość konfiguracji zapory tak wygląda w tej chwili, w iptables działa przy nftables lipa table ip filter { chain input { type filter hook input priority filter; policy accept; ct state established,related counter packets 1527 bytes 133094 accept tcp dport 22 counter packets 31 bytes 9569 accept tcp dport 51820 counter packets 0 bytes 0 accept iifname "lo" counter packets 0 bytes 0 accept counter packets 77 bytes 6528 drop } chain forward { type filter hook forward priority filter; policy accept; ct state established,related counter packets 0 bytes 0 accept iifname "wg0" oifname "wg0" ct state new counter packets 0 bytes 0 accept } } table ip nat { chain postrouting { type nat hook postrouting priority srcnat; policy accept; oif "eth0" ip saddr 10.200.200.0/24 counter packets 0 bytes 0 masquerade } } Jakby ktoś miał jakieś pomysły to prosiłbym o pomoc.
  13. CentOS 8 z końcem 2021 roku zostaje wycofany a CentOS 7 wspierany do 2024 roku i to podobno tylko łatkami bezpieczeństwa. Przynajmniej z tego co wyczytałem w różnych źródłach. Ja używam CentOS 7. Nie widziałem potrzeby instalowania nowszej wersji dla takich usług jak u mnie więc uważam że w zupełności wystarczający był. Nie jestem przekonany co do wersji Stream. Może dlatego, że do końca nie rozumiem idei jej idei. Określają go jako jakiś kolejny etap przejściowy/rozwojowy pomiędzy Fedorą, która już jest czymś takim a RHEL. Może źle to interpretuje ale dla mnie to kolejna wersja, która jest zbędna, stworzona po to żeby CentOS też miał coś podobnego do Fedory. Wracając do tematu to czy Fedora często stwarza jakieś problemy przy upgrade? Nie jestem doświadczony jak zawodowy administrator. Bardziej do tego pytanie statystycznie podejść. Chodzi mi o jakieś zależności softu, szukanie i doinstalowywanie pakietów, też przy zamianie jądra itp. Czy można załatwić sprawę 2-4 komendami dnf ... ? Jak rozumieć krótki czas wsparcia? Repozytoria z których są robione aktualizacje np. iptables czy nginx są zamykane lub pakiety w nich do danej wersji przestają być aktualizowane? Bo to, że w nowej wersji Fedory zostanie wprowadzony jakieś nowy soft do muzyki czy GUI Gnome 40 jak to chyba miało miejsce w Fedora 34 to mnie nie interesuje wcale.
  14. Witam Po oficjalnej informacji, że projekt dystrybucji CentOS ma być zamknięty postanowiłem przesiąść się na distro Fedora. Nigdy nie pracowałem na Fedorze. Nie lubię zbytnio dystrybucji Debian i debiano pochodnych wynylazków typu Ubuntu, który moim zdaniem nie jest przyjazny do zastosowań serwerowych tak jak pochodne RedHata. Posiadam serwer z vpn, www, mysql, ssh, smb + chmura plików w tym jest jeszcze zainstalowane GUI - xfce z którego rzadko się korzysta. Wszystko jest praktycznie robione zdalnie przez ssh. Moje pytanie brzmi: czy warto robić upgrade Fedory często przy takich usługach na serwerze? Zdania adminów są podzielone. Niektórzy robią to do każdej nowej stabilnej wersji distro inni wtedy gdy wyjdzie nowa stabilna wersja jądra linuxa razem z nową Fedorą a usługi w/w i zabezpieczenia np. iptables oraz upgrade php wykonują manualnie przez 'dnf upgrade ...'
×
×
  • Create New...