Routing między vlanami

[roberto100]

Czy możecie mi pomóc w zrozumieniu jednej rzeczy. Mam w SRX240H stworzoną jedną instancję (zones/screens) o nazwie "local" a w niej np. trzy vlany (dane przykładowe):
"1500 TRUNK"
"100 management"
"50 komputers"

Do każdego z tych vlanów są odpowiednio adresy:
vlan100 (RVI vlan.10) - 192.168.100.0/24
(ip adress gw: 192.168.100.1)
i w nim mam swiche, access pointy, itp.

vlan50 (RVI - vlan.5) - 192.168.50.0/21
(ip adress gw: 192.168.50.1)
i w nim komputery użytkowników.
oraz uruchomiony DHCP.

Oba powyższe VLANY są puszczone TRUNK-iem (vlan 1500) do swicha i tam rozszyte na poszczególne porty.

Problem: mogę spokojnie pingować i wchodzić na poszczególne adresy MIĘDZY tymi vlanami. A przecież z założenia nie powinno być możliwości wchodzenia między VLANAMI.

Czy problemem jest to, że oba te VLANY są w jednej instancji (zones/screens) - a czy przypadkiem nie powinny być rozdzielone na dwie oddzielne instancje, aby nie było MIĘDZY nimi ruchu, tzn. aby komputery z vlanu 50 nie mogły pingować, ani wyświetlać swichy po http z vlanu 100?

[seba766]

Domyślnie na SRX intrazone jest wyblokowany. Czy możesz pokazać jakie masz rulki?

[Szefo89]

Oba powyższe VLANY są puszczone TRUNK-iem (vlan 1500) do swicha i tam rozszyte na poszczególne porty.

Nie do końca rozumiem to zdanie, co dokładnie robi VLAN 1500? Zakładam że obok niego masz puszczone VLANy 50 i 100, tak?

Pytanie w jaki sposób masz rozłożone interfejsy na security-zones. Jeżeli znajdują się one w tej samej, np. trust, to zobacz czy nie masz polityki from-zone trust to-zone trust, bo tylko ona byłaby w stanie przepuścić taki ruch. Nie musisz interfejsów rozdzielać na różne instancje, na SRX wszystko działa w obrębie polityk, więc jeżeli usuniesz politykę, która przepuszcza ten ruch, to przestanie on działać i możesz wtedy przepuścić tylko to co chcesz.

Gdybyś nie znalazł tej polityki, to najłatwiej możesz ją zlokalizować w następujący sposób:
1. Uruchom ping z jednej sieci do drugiej i zostaw na dłuższy czas (na Linuxie działa to domyślnie, na Windowsie opcja -t)
2. Na SRX wykonaj komendę:

Kod: Zaznacz cały

show security flow session protocol icmp

3. Powinieneś zobaczyć sporo sesji tego typu:

Kod: Zaznacz cały

Session ID: 335213, Policy name: NAZWA-POLITYKI/143, State: Active, Timeout: 4, Valid
  In: ADRES-SRC/36133 --> ADRES-DST/1;icmp, Conn Tag: 0x0, If: INTERFEJS-IN, Pkts: 1, Bytes: 60,
  Out: ADRES-DST/1 --> ADRES-SRC/36133;icmp, Conn Tag: 0x0, If: INTERFEJS-OUT, Pkts: 1, Bytes: 60,

W pierwszej linii będzie nazwa polityki łamana na jakąś liczbę, tym się nie przejmuj, przeszukaj konfigurację pod kątem tej nazwy:

Kod: Zaznacz cały

show configuration | display set| match NAZWA-POLITYKI

Zobaczysz dokładnie jak wygląda polityka, która przepuszcza ten ruch.

[roberto100]

Oba powyższe VLANY są puszczone TRUNK-iem (vlan 1500) do swicha i tam rozszyte na poszczególne porty.

Nie do końca rozumiem to zdanie, co dokładnie robi VLAN 1500? Zakładam że obok niego masz puszczone VLANy 50 i 100, tak?

TAK dla przykładu ten 1500 to tylko TRUNK i przez niego idą 50 i 100.

[Szefo89]

Jak możesz to wrzuć konfigurację interfejsów, będzie łatwiej I wykonaj tę procedurę co wyżej wrzuciłem, powinieneś znaleźć regułę przepuszczającą ruch. Gdyby tak się nie stało, to podeślij proszę wynik komendy

Kod: Zaznacz cały

show configuration security policies | display set

Oczywiście możesz zamazać poufne dane typu adresy IP czy nazwy klientów.

[roberto100]

Pytanie w jaki sposób masz rozłożone interfejsy na security-zones. Jeżeli znajdują się one w tej samej, np. trust, to zobacz czy nie masz polityki from-zone trust to-zone trust, bo tylko ona byłaby w stanie przepuścić taki ruch. Nie musisz interfejsów rozdzielać na różne instancje, na SRX wszystko działa w obrębie polityk, więc jeżeli usuniesz politykę, która przepuszcza ten ruch, to przestanie on działać i możesz wtedy przepuścić tylko to co chcesz.
[/quote]

Mam politykę from-zone trust to-zone trust (u mnie się ona nazywa: local to local), która mogła by podpadać: np. mam jedną taką politykę, aby z sieci komputerów był dostęp do drukarki, która jest w innej podsieci:

policy printer {
match {
source-address 192.168.50.0;
destination-address [ printer 192.168.100.16 ];
application any;
}
then {
permit;
}
}

Ale jest to konkretne wskazanie na dany ip z drugiego vlana - więc nie powinno mieć to znaczenia, ale mam wrażenie, ze cokolwiek w niej zmienię - to nic się nie zmienia w rzeczywistości czy ją deaktywuję, czy nie. To tak, jakby jakiś routing wewnętrzny był między vlanami...

[roberto100]

Jak możesz to wrzuć konfigurację interfejsów, będzie łatwiej I wykonaj tę procedurę co wyżej wrzuciłem, powinieneś znaleźć regułę przepuszczającą ruch. Gdyby tak się nie stało, to podeślij proszę wynik komendy

Kod: Zaznacz cały

show configuration security policies | display set

Oczywiście możesz zamazać poufne dane typu adresy IP czy nazwy klientów.

Dobra. Dziękuję za podpowiedź. Powalczę z testem i zobaczę. A jutro jak będę na miejscu - pozwolę sobie napisać.

[Szefo89]

policy printer {
match {
source-address 192.168.50.0;
destination-address [ printer 192.168.100.16 ];
application any;
}
then {
permit;
}
}

Juniper operuje na nazwach, nie na IPkach, więc za tymi wpisami kryją się jakieś podsieci. Sprawdź konfigurację security-zone, a w szczególności zwróć uwagę na sekcję address-book, zobaczysz co się kryje pod tymi nazwami z polityk:

Kod: Zaznacz cały

show configuration security zones security-zone local

Ale jest to konkretne wskazanie na dany ip z drugiego vlana - więc nie powinno mieć to znaczenia, ale mam wrażenie, ze cokolwiek w niej zmienię - to nic się nie zmienia w rzeczywistości czy ją deaktywuję, czy nie. To tak, jakby jakiś routing wewnętrzny był między vlanami...

Może masz coś namieszane z routingiem, sprawdź na maszynach czy mają ustawioną bramę domyślną skierowaną na SRX i czy nie mają jakichś dodatkowych routingów do konkretnych podsieci, być może przed SRX stoi coś jeszcze co powoduje taki problem.

[roberto100]

Dzięki Szefo89 za podpowiedź
Po sprawdzeniu: show security flow session protocol icmp okazało się, którą polityka była tego przyczyną.
Problem rozwiązany.

[Szefo89]

Nie ma problemu, fajnie że udało się namierzyć przyczynę