📬 ISN 227: Ansible w Produkcji, Bot Sieciowy i dlaczego OSPF nie milknie!

Blokujesz ICMP?

Should I block ICMP?

Should I block ICMP

ShouldIBlockICMP.comJason Ashworth

Blokujesz cały ruch ICMP na firewallach? To może być źródłem twoich problemów z siecią. Choć ICMP faktycznie niesie ryzyka bezpieczeństwa, całkowite zablokowanie tego protokołu niszczy kluczowe mechanizmy sieciowe.

PMTUD i cicha czarna dziura

Najpoważniejszy problem dotyczy Path MTU Discovery. Gdy blokujesz ICMP Type 3 Code 4 (IPv4) lub Type 2 Code 0 (IPv6), uniemożliwiasz routerom informowanie hostów o zbyt dużych pakietach. Efekt? TCP handshake przechodzi bez problemu (małe pakiety), ale transfer danych kompletnie się zawiesza. Pakiety sąDropowane w ciszy, sender retransmituje w nieskończoność interpretując brak ACK jako congestion.

RFC 4821 wprowadza PLPMTUD jako workaround, ale to tylko plaster na ranę – mniej efektywny i obciążający sieć próbami inkrementalnego zwiększania MSS. Po prostu przepuść te komunikaty ICMP.

Co przepuszczać selektywnie

Echo Request/Reply (ping) – blokuj na granicy DMZ jeśli musisz, ale wewnątrz sieci? Utrudniasz troubleshooting bez realnego zysku. Twój web server i tak świeci na porcie 80. Możesz też filtrować kierunkowo: echo request OUT, echo reply IN.

Time Exceeded – bez tego traceroute pokazuje same gwiazdki. Debugowanie routingu staje się męką, a ty dostajesz ticket "sieć nie działa" bez możliwości szybkiej diagnozy.

NDP dla IPv6 (Type 133-137) – absolutnie krytyczne wewnątrz sieci. To nie ARP; IPv6 bez NDP i SLAAC po prostu nie funkcjonuje. Zero kompromisów.

Rate limiting jako linia obrony

1000 pingów na sekundę to nie jest legitymny ruch – to atak. Zamiast blokować wszystko, ustaw sensowne rate limity dla każdego typu ICMP. Ochronisz CPU routerów i obronisz się przed abuse, zachowując funkcjonalność protokołu.

Pasywne interfejsy OSPF, które gadają

Cisco IOS/XR OSPFv2 Not-So-Passive Interfaces « ipSpace.net blog

What’s wrong with me? Why do I have to uncover another weirdness every single time I run netlab integration tests on a new platform? Today, it’s Cisco IOS/XR (release 25.2.1) and its understanding of what “passive” means. According to the corresponding documentation, the passive interface configuration command is exactly what I understood it to be: Use the passive command in appropriate mode to suppress the sending of OSPF protocol operation on an interface. However, when I ran the OSPFv2 passive interface integration test with an IOS/XR container, it kept failing with neighbor is in Init state (the first and only time I ever encountered such an error after testing over two dozen platforms).

ipSpace Logo

Cisco IOS XR 25.2.1 ma intrygujący bug: interfejsy OSPF oznaczone jako passive wysyłają pakiety Hello tuż po konfiguracji. Problem? Nie do końca rozumieją, co oznacza "pasywny".

Dokumentacja Cisco jasno stwierdza: komenda passive ma "suppress the sending of OSPF protocol operation". W praktyce wygląda to inaczej. Test integracyjny z netlab konsekwentnie kończy się błędem neighbor is in Init state – objawem, którego autor nigdy nie widział na ponad 20 testowanych platformach.

Konfiguracja wygląda poprawnie:

router ospf 1
 area 0.0.0.0
  interface GigabitEthernet0/0/0/1
   passive enable

Tcpdump ujawnia prawdę: IOS XR po skonfigurowaniu interfejsu wysyła dwa pakiety OSPF Hello w odstępie 10 ms, po czym zamyka się na głucho. FRRouting po drugiej stronie linku dostaje te Hello, odpowiada, ale IOS XR już milczy. Efekt: sąsiad zawiśnięty w stanie Init.

IOS XR używa transakcyjnej konfiguracji z commit – teoretycznie wszystkie zmiany powinny być atomowe. Najwyraźniej nie do końca. Platforma zachowuje się jakby konfiguracja OSPF i komenda passive były przetwarzane z minimalnym opóźnieniem, pozwalającym na wystrzelenie dwóch Hello.

Nawet transakcyjne systemy konfiguracyjne w enterprise-grade platformach mają race conditions. Przy testowaniu integracji OSPF warto mieć tcpdump pod ręką – dokumentacja nie zawsze odzwierciedla rzeczywistość. A jeśli widzicie Init state z IOS XR na pasywnych interfejsach – teraz wiecie dlaczego.

Bot do zarządzania infrastrukturą

GitHub - h-network/h-cli: Natural language infrastructure management

Natural language infrastructure management. Contribute to h-network/h-cli development by creating an account on GitHub.

GitHubh-network

h-cli to bot Telegrama zasilany przez Claude Code, który pozwala na zarządzanie infrastrukturą sieciową za pomocą naturalnego języka. Wystarczy wysłać prostą wiadomość, a bot wykona odpowiednie polecenia, np. skanowanie sieci, konfigurację routerów w EVE-NG czy tworzenie sesji BGP, automatycznie integrując się z NetBox. System działa w bezpiecznym środowisku kontenerowym z wielowarstwowym modelem ochrony opartym na zasadach Asimova, które zapobiegają wykonywaniu niebezpiecznych komend.

Baza Geolokalizacji

IP66 — Free IP Geolocation Database

A free, open IP Geolocation database in MMDB format. Includes ASN, country, and continent data. Updated daily. No license restrictions.

IP66Cloud66, Inc.

INFO: ip66 to darmowa, codziennie aktualizowana baza danych geolokalizacji IP w formacie MMDB, oferująca szczegółowe informacje takie jak ASN, kraj i kontynent. Możesz ją wykorzystać bez ograniczeń i bez kluczy licencyjnych w dowolnym projekcie – osobistym lub komercyjnym. Baza jest w pełni kompatybilna z dowolnym czytnikiem MMDB i obsługuje IPv4 oraz IPv6.

Modułowa architektura Ansible w produkcji