ich hab mich gestern mim c887er rumgespielt und bin kerzengrad in den beton gefahren, weil ich die netzstruktur von aontv am front-end nicht berücksichtigt hab.
die gesamte thematik fällt in die kategorie:
"warum is die ach so pöse ta so 'bescheuert' und schränkt bei ihren cpe's lanseitig die ip ranges auf 10.0.0.0/24, 192.168.0.0/23 ein?".
ich war in der vergangenheit schon hinreichend oft mit diesbezüglichen fragen konfrontiert, hatte auch so meine vermutungen, wirklch beweisen konnte ich es aber nicht. jetzt hingegen, nach dem betonfahrer, bin ich um 1 bit schlauer- es ist schlicht und ergreifend eine sicherheitsmaßnahme...
was is passiert?
1. die struktur der front nets von aontv/ngtv:
die ta verwendet /22er netze aus 10.0.0.0/8 am front-end zum user, da hat sich beim übergang aontv -> ngtv nix geändert. i.e. der user kriegt, abhängig vom standort, eine ip aus
10.x.y+[0-3].z/22 mit y = 0 (mod 4) und gate zum core net von aontv/ngtv 10.x.(y+3).254.
bei mir sieht das z.b. so aus:
- Code: Alles auswählen
Rou88>sin | i 836
ATM0.836 10.86.62.5 YES DHCP up up
Rou88>sir
...
...
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
S* 0.0.0.0/0 is directly connected, Dialer0
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks --+
S 10.1.10.0/24 [254/0] via 10.86.63.254 |
C 10.86.60.0/22 is directly connected, ATM0.836 +--> ! *** das is das prob!
L 10.86.62.5/32 is directly connected, ATM0.836 ------+
77.0.0.0/32 is subnetted, 1 subnets
C 77.*.*.* is directly connected, Dialer0
78.0.0.0/32 is subnetted, 1 subnets
C 78.*.*.* is directly connected, Dialer0
80.0.0.0/32 is subnetted, 3 subnets
S 80.75.46.39 [254/0] via 10.86.63.254
S 80.75.55.77 [254/0] via 10.86.63.254
S 80.75.55.101 [254/0] via 10.86.63.254
172.17.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.17.2.0/24 is directly connected, Vlan1
L 172.17.2.132/32 is directly connected, Vlan1
188.21.0.0/16 is variably subnetted, 2 subnets, 2 masks
S 188.21.248.0/22 [254/0] via 10.86.63.254
S 188.21.252.0/23 [254/0] via 10.86.63.254
S 213.33.32.0/21 [254/0] via 10.86.63.254
S 213.33.40.0/23 [254/0] via 10.86.63.254
S 213.33.42.0/24 [254/0] via 10.86.63.254
Rou88>
bei mir ist also x = 86 und y = 60 bzw. y+3 = 63 und somit gate = 10.86.63.254.
2. welchen fehler hab ich bei den wildcard masks gemacht?
die gesamte aontv-ios konfig is mehr oder weniger eine primitive übersetzung der st/tg konfig (zeilen, die in den folgenden code-abschnitten mit "! ***" beginnen, sind meine kommentare):
der cisco ist dhcp- und dns-server, die stb(s) kriegen adressen aus dem bereich 172.17.2.8/29:
- Code: Alles auswählen
ip dhcp pool lan
network 172.17.2.0 255.255.255.0
default-router 172.17.2.132
dns-server 172.17.2.132
class iptv
address range 172.17.2.8 172.17.2.15
class lan
address range 172.17.2.33 172.17.2.62
!
!
ip dhcp class iptv
option 60 hex 414442333830306669737973
!
ip dhcp class lan
es sind 2 views für aontv und data eingerichtet, die view aontv ist für die domains
NGM.HIGHWAY.TELEKOM.AT und CPE-MGMT.AT zuständig. die dns-server werden via dhcp (aontv) und ipcp (data) bezogen und in die views importiert.
- Code: Alles auswählen
ip dns view aontv
logging
domain resolver source-interface ATM0.836
domain name-server interface ATM0.836
ip dns view data
domain resolver source-interface Dialer0
domain name-server interface Dialer0
ip dns view-list data-aontv
view aontv 10
restrict name-group 1
view data 100
ip dns name-list 1 permit NGM\.HIGHWAY\.TELEKOM\.AT
ip dns name-list 1 permit CPE-MGMT\.AT
ip dns server view-group data-aontv
ip dns server
da überhaupt keine hosts eingetragen sind, muß der resolver bei jeder dns request aus dem lan selbst die entsprechenden dns-server konsultieren. das ist der springende punkt, s. weiter unten.
die schnittstellen sind wie üblich konfiguriert: atm08.838 und der dialer0 sind "nat outside", vlan1 ist "nat inside".
- Code: Alles auswählen
!*** atm0.838 kriegt die 10.86.62.5/22
interface ATM0.836 point-to-point
description Routed ETHoA on 8.36, aontv
no ip dhcp client request static-route
no ip dhcp client request router
ip dhcp client request classless-static-route
ip dhcp client class-id ADB3800fisys
ip address dhcp
ip pim sparse-dense-mode
ip nat outside
...
...
! *** der dialer kriegt die 78.*.*.*
interface Dialer0
ip address negotiated
...
ip nat outside
...
...
interface Vlan1
ip address 172.17.2.132 255.255.255.0
...
ip nat inside
...
...
die maskierung von data und ucast iptv wird von den acls "ppp" und "aontv" gesteuert.
- Code: Alles auswählen
ip nat inside source list aontv interface ATM0.836 overload
ip nat inside source list ppp interface Dialer0 overload
so, und jetzt die 2 acls. normalerweise würde man das setzen:
- Code: Alles auswählen
ip access-list standard aontv
permit 172.17.2.8 0.0.0.7
ip access-list standard ppp
deny 172.17.2.8 0.0.0.7
permit 172.17.2.0 0.0.0.255
hab ich in dem fall "sicherheitshalber" nicht gemacht, weil der user, für den diese config bestimmt ist, gern an den adreßbereichen rumschraubt und dann oft nicht an die acls für die maskierung denkt. das ganze wurde leicht verallgemeinert:
- Code: Alles auswählen
ip access-list standard aontv
permit 10.0.0.8 0.255.255.7
permit 172.16.0.8 0.15.255.7
permit 192.168.0.8 0.0.255.7
ip access-list standard ppp
deny 10.0.0.8 0.255.255.7
deny 172.16.0.8 0.15.255.7
deny 192.168.0.8 0.0.255.7
permit 10.0.0.0 0.255.255.255 <-- !*** net so guat!
permit 172.16.0.0 0.15.255.255
permit 192.168.0.0 0.0.255.255
das ergebnis dieser "genialen" verallgemeinerung waren eine fehlermeldung auf der glotze:
"Achtung;
Bitte geben Sie Ihrer Mediabox etwas Zeit. bla-bla-bla...[ID: 9408]"
und so richtig idyllische packet traces:
- stbR220_no_name_resolution.png (20.85 KiB) 6039-mal betrachtet
mit dem packet tracing am cisc sieht man, was passiert:
- Code: Alles auswählen
! *** die stb (172.17.2.8) will die ip von "acs.cpe-mgmt.at" wissen:
...
Jun 28 10:58:04.904: IP: s=172.17.2.8 (Vlan1), d=172.17.2.132 (Vlan1), len 61, rcvd 3
Jun 28 10:58:04.904: IP: s=172.17.2.8 (Vlan1), d=172.17.2.132, len 61, stop process pak for forus packet
Jun 28 10:58:04.904: %DNS-6-LOG_ACCESS: DNS View aontv used for client 172.17.2.8/2985, querying A 'acs.cpe-mgmt.at'
! ***
! *** der resolver schickt die anfrage zum ersten dns-server von aontv (213.33.42.97).
! *** die src-ip stimmt- noch...
! ***
Jun 28 10:58:04.904: IP: s=10.86.62.5 (local), d=213.33.42.97, len 61, local feature, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Jun 28 10:58:04.904: IP: tableid=0, s=10.86.62.5 (local), d=213.33.42.97 (ATM0.836), routed via RIB
Jun 28 10:58:04.904: IP: s=10.86.62.5 (local), d=213.33.42.97 (ATM0.836), len 61, sending
! ***
! *** jetzt stimmt sie aber schon nimmer, der cisc maskiert die 10.86.62.5
! *** mit der dialer-ip 78.*.*.* ...
! ***
Jun 28 10:58:04.904: IP: s=78.*.*.* (local), d=213.33.42.97 (ATM0.836), len 61, output feature,
Post-routing NAT Outside(24), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
...
! ***
! *** ...und schickt dann das paket auch so übers atm0.836 intf raus.
! *** antwort kriegt er keine- echt bled... :D
! ***
Jun 28 10:58:04.904: IP: s=78.*.*.* (local), d=213.33.42.97 (ATM0.836), len 61, sending full packet
3. fazit der geschicht:
wenn ihr aontv mit fremdroutern betreibt, dann paßt bei den adreßbereichen und (wildcard) masks auf, sonst kanns schon lustig werden. derartige probs sind manchmal schwer zu orten. hab für den kas sicher eine halbe stunde gebraucht.
lg
zid
