Setting routing table for interface may cause unexpected results.

Po ustawieniu routing.table w interfejsie można spodziewać się że cały ruch związany z interfejsem zostanie odseparowany do osobnej tabeli routingu, jednak w obecnej implementacji może to prowadzić do błędnego założenia o podniesionym bezpieczeństwie.

Problemy

W obecnej implementacji zostaną założone reguły kierujące ruch oznaczony adresem źródłowym z podsieci przypisanych do interfejsu co prowadzi do dwóch zachowań niezgodnych z oczekiwaniami:

Problem 1:

• połączenia wychodzące w sieci oznaczonej tabelą, zostaną wysłane standardową tabelą routingu (co jest oczekiwane)
• pakiet zwrotny z uwagi na adres źródłowy trafi do docelowej tabeli routingu (poprzez definicję opierającą się o źródło)
• brak pełnej wiedzy w tej tabeli o pierwotnym źródle (a co za tym idzie powrotnym celu) może prowadzić do przekazania go do bramy zewnętrznej, zamiast na przykład do kontenera (172.17.0.x)

Problem 2.

• pakiety z innych sieci niż oznaczone w tabeli przychodzące na interfejsie oznaczonym tabelą trafią do domyślnej tabeli routingu, podczas gdy jako użytkownik roli spodziewał bym się iż interfejs jest w pełni odseparowany w warstwie L3

Rozwiązania

⚠ Rozwiązanie pierwszego problemu uwidacznia problem drugi, co za tym idzie oba problemy należy rozwiązać jednocześnie. ⚠

Rozwiązanie problemu 1:

Dodanie parametru iif lo do routing-rule. Zgodnie z dokumentacją spowoduje, że pakiet (niezależnie od interfejsu) trafiający do tabeli docelowej (na podstawie adresu źródła) nie zostanie przez tą tabele routowany, bo nie przyszedł z interfejsu lo (nie był wewnętrzny) (zachowanie oczekiwane, ale uwidacznia Problem 2)

Rozwiązanie problemu 2:

Dodanie dodatkowej reguły postaci:

 priority 1 iif {{ NAME_OF_INTERFEJS }} table {{ ROUTING_TABLE_ID }}

sprawi ze wszystkie pakiety przychodzące na danym interfejsie zostaną przyłączone do dedykowanej tabeli routingu.