[ azzpoz @ 12.06.2014. 18:11 ] @
| 1. ruter 192.168.0.0 255.255.255.192
2. ruter 192.168.0.64 255.255.255.224
Potrebno je zabraniti hostovima unutar 1. rutera da pingaju lan 2. rutera.
access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31
access-list 100 permit ip any any
Postavim ACL na serijski interfejs(out) 1. rutera i blokira se icmp(ping).
Kako da uspijem iz LAN-a (2. rutera) pingati hostove u lanu 1. rutera, a da se paketi ne blokiraju zbog ACL, kada putuju nazad?
[Ovu poruku je menjao azzpoz dana 12.06.2014. u 19:24 GMT+1] |
[ PaStvarno @ 14.06.2014. 07:50 ] @
imaš 2 access-liste (ako nisi slučajno pogrešio u kucanju)
access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31
ova access lista ima implict deny na kraju i blokira sve
access-list 100 permit ip any any
ova access lista ne radi ništa, dozvoljava sve, pa onda je isto kao da nisi ni stavio access listu
ako hoćeš da ti bude blokiran ping, ali dozvoljen ping reply možeš dodati
access-list 110 permit icmp any any echo-reply
access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31
access-list 110 permit ip any any
[ zeenmc @ 16.06.2014. 10:41 ] @
Citat:
PaStvarno: imaš 2 access-liste (ako nisi slučajno pogrešio u kucanju)
access-list
100 permit ip any any
ova access lista ne radi ništa, dozvoljava sve, pa onda je isto kao da nisi ni stavio access listu
bas suprotno, ACL 100 je veoma bitna, barem u realnom zivotu xD, jer prvi, tj gornji redovi bivaju deny statement, pa posle njih moras pustiti sve sto ti treba da prodje kroz ruter, ili kao sto je gore napisano, acess-list 100 permit ip any any, ovo se radi zbog jer na kraju svake liste deny ip any any... paketi koji se budu podudarali sa ACL 110, nece ni stici do 100 xD
[ PaStvarno @ 16.06.2014. 17:02 ] @
a) svi paketi se podudaraju sa ACL 110 zbog implicit deny
b) u realnom životu 2 access liste se ne mogu staviti na interface u out pravcu
[ azzpoz @ 17.06.2014. 00:35 ] @
Slučajno je napisano 110 i 100...
U svakom slučaju, hvala.
[ zeenmc @ 17.06.2014. 20:35 ] @
grrr, ja sam pogresio, mislio sam da su 100 i 110 redovi u jednoj istoj ACL, mislio sam da se podrazumeva da je to jedna te ista ACL, bas iz razloga sto ide jedna ACL na jednom interfejsu u jednom pravcu....:)
[ B3R1 @ 18.06.2014. 13:32 ] @
Citat:
PaStvarno:
access-list 110 permit icmp any any echo-reply
access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31
access-list 110 permit ip any any
ICMP se ne koristi samo za ping (echo/echo-reply), vec i za mnoge druge stvari. Izmedju ostalog i za PMTUD, koji ako ne radi kako valja cesto pravi glavobolje. Ja bih radije to uradio ovako:
access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31
echo
access-list 110 permit ip any any
Time se onemogucava ICMP Echo (Type=8, Code=0), ali se dozvoljava Echo Reply (Type=0, Code=0), kao i sve ostale ICMP poruke.
[ Aleksandar Đokić @ 19.06.2014. 15:42 ] @
Beri, jel moze malo vise o PMTUD procesu?
Svako moze da procita na wiki-ju, ali bih voleo da procitam tvoje objasnjenje.
[ B3R1 @ 27.06.2014. 15:11 ] @
Kao sto si i sam rekao, klasicnu pricu mozes da nadjes na gomili sajtova ili da procitas RFC 1191. Ukratko, su source (S) i destination (D) host povezani nizom rutera na sledeci nacin:
S --- R1 --- R2 --- R3 --- ... ---- Rn --- D
i ako je na S hostu aktiviran PMTUD (Linux: /proc/sys/net/ipv4/ip_no_pmtu_disc = 0) tada ce on smatrati da su ruteri R1 ... Rn sposobni da bez fragmentacije prenesu IP pakete od S ka D, odnosno da u mrezi izmedju S i D nema nijednog linka ciji je MTU manji od MTU na linku S-R1. Stoga, umesto da S salje IP pakete sa resetovanim DF bitom (DF=0) i prepusti ruterima R1 ... Rn da se sami snalaze i fragmentiraju paket kako im je volja, S ce postaviti DF=1 i pokusace da posalje paket ka D. Ako iz bilo kog razloga neki od rutera R1 ... Rn ne moze da dalje prosledi takav paket (npr. ako je MTU (R2,R3) < MTU (S,R1)), taj ruter (u primeru: R2) ce o tome obavestiti izvorisni host (S) ICMP porukom Destination Unreachable - Fragmentation Needed and DF Set (Type=3, Code=4); u "unused" polje ICMP poruke ruter ce kopirati MTU interfejsa koji pravi problem (u primeru R2-R3). Kada primi ICMP poruku, host S ce pokusati da posalje pakete ponovo, ali uz MTU koji odgovara vrednosti koju je dobio u ICMP poruci od rutera R2. Postupak se ponavlja sve dok se nijedan ruter R1 ... Rn vise ne buni, ili dok se ne dostigne minimalni standardni MTU (576 bajtova).
Dok je kod IPv4 uvek moguce iskljuciti PMTUD i prepustiti ruterima da fragmentiraju pakete, kod IPv6 to nije moguce - PMTUD je obavezan, ruteri ne vrse fragmentaciju IPv6 paketa. Osim PMTUD, ICMPv6 se koristi i za ND (ekvivalent ARP u IPv6). Zbog toga je blokiranje ICMPv6 poruka prilicno nezgodna stvar, koja moze da dovede i do totalnog prekida komunikacije.
Problem kod PMTUD nastaje kada host S nije u stanju da prima ICMP poruke od rutera iz bilo kog razloga (firewall/acl negde na putu, gubitak ICMP paketa usled opterecenja linkova itd.) i ako TCP implementacija nije dovoljno inteligentna da prepozna tu situaciju. U tom slucaju, narocito kod starijih uredjaja i OS cesto se desasvalo da TCP nastavi sa retransmisijama dok ne istekne timeout i sesija puca. Tipican efekat koji su korisnici cesto primecivali su nepotpune web stranice, slike ucitane do pola itd. Vecina novijih TCP implementacija koristi PLPMTUD (RFC4821) - mehanizam koji omogucava TCP-u da na pocetku veze posalje par proba i ustanovi end-to-end MTU, oslanjajuci se na retransmisije. Na Linuxu se ova opcija moze da ukljuci sa "echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing".
Srodan problem, danas nazalost veoma cest, je vezan za mreze gde se koristi MPLS, gde ponekad moze da dodje do ovakve situacije:
S === PE1 === P1 --- P2 --- ... --- Pn --- PE2 --- D
Na ovoj slicici MTU na linku S-PE1 i PE1-P je veci od MTU u ostatku mreze. Primera radi, neka je MTU(S,PE1) = 2000 bajtova, MTU (PE1,P) = 4470, a u ostatku mreze 1500. Ono sto se tu desava je da source host (S) smatra da je MTU cele mreze 2000 bajtova i pokusava da posalje paket te duzine preko rutera PE1. Ruter PE1 "vidi" sledeci ruter u nizu (P) preko linka sa MTU=4470 bajtova i salje paket ka tom ruteru. Medjutim, kada PE1 ruter posalje paket on mu dodaje MPLS labelu i od tog trenutka P ruteri na putu izmedju PE1 i PE2 manipulisu samo MPLS labelama. ICMP poruke sa P rutera ne stizu nigde. P1 ce detektovati MTU problem na linku P1-P2 i poslace ICMP poruku ka hostu S, ali ta poruka nece stici nigde, jer P ruteri nemaju rute niti su u stanju da formiraju MPLS paket - oni samo vrse zamenu labele drugom labelom. Zbog toga je veoma bitno da se u MPLS mrezama ujednace MTU vrednosti na svim linkovima gde god je to moguce.
[ Aleksandar Đokić @ 01.07.2014. 01:42 ] @
Ok, hvala, jasno kao dan. Svidja mi se ovaj PLPMTUD.
Tekst koji sam ja nasao i cini mi se da vredi procitati:
http://conferences.sigcomm.org/imc/2010/papers/p102.pdf
Copyright (C) 2001-2024 by www.elitesecurity.org. All rights reserved.