LAN - FW - DHCPserver
A FW -on fut a dhcp -relay. Lanban egy gépet rádugok a hálóra, a dhcp request eljut dhcp serverig, ő válaszol is, de valamiért a dhcp reply nem érkezik meg már arra az interfészre sem, ami a FW -nak a LAN felé néz interfésze, viszont a DHCP felé eső interfészen tcpdump -al látom, hogy jön vissza dhcp replay.
A dhcp-relay -ben options="" mezőben kell esetleg megadni valamit, hogy visszafelé is forwardoljon?
- 2154 megtekintés
Hozzászólások
Megfogja a tuzfal?
- A hozzászóláshoz be kell jelentkezni
Három kérdés:
- A tűzfal átengedi?
- A DHCP relay agent hallgat a szerver felőli interfészen is?
- A tűzfalnak a DHCP szerver felőli interfészén unicastként vagy broadcastként látszik a válasz?
"kell esetleg megadni valamit, hogy visszafelé is forwardoljon?"
Nem.
- A hozzászóláshoz be kell jelentkezni
a tűzfal átengedi, mert még nincs rajta a tűzfal. ping megy.
igen hallgat:
SERVERS="10.10.60.2" --> dhcpserver cime, pingelhető
INTERFACES="eth0" --> ezen lódg egy gép aminek cimet akarok adni
most addig eljutottam, hogy lcseréltem a dhcp-relay -t dchp3-relay -reés már dhcp reply -t sem látok a FW dhcpszerver felé néző interfészén.
- A hozzászóláshoz be kell jelentkezni
mégvalami , a FW -on az ip-forwarding és a masquerade be van kapcsolva.
- A hozzászóláshoz be kell jelentkezni
mégvalami, azt látom tcpdump -al, hogy a fw arp who is -ezik a dhcpszerver felé, jön is a válasz, ezután továbbitja a dhcp requestet a dhcp felé és ezután valami multicast -os cimeket látok de ezeket nemtudom mik.
- A hozzászóláshoz be kell jelentkezni
a xenbr6 bridge -en ül a dhcp virtuálisgép. a dom0 a fizikai hosztgép, ehhez van csatolva a xenbr6 bridge.
dom0:~# tcpdump -i xenbr6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xenbr6, link-type EN10MB (Ethernet), capture size 96 bytes
10:53:13.579762 arp who-has dnsdhcp.xxx.hu tell dom0.local
10:53:13.579868 arp reply dnsdhcp.xxx.hu is-at 00:16:3e:1a:34:a6 (oui Unknown)
10:53:13.579884 IP dom0.local.bootps > dnsdhcp.xxx.hu.bootps: BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44 (oui Unknown), length 300
10:53:13.679839 IP dom0.local.mdns > 224.0.0.251.mdns: 0 [2q] PTR? 255.255.255.255.in-addr.arpa.[|domain]
10:53:13.680246 IP dom0.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain]
10:53:13.789959 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 251.0.0.224.in-addr.arpa. (42)
10:53:14.689863 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 255.255.255.255.in-addr.arpa. (46)
10:53:14.799783 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 251.0.0.224.in-addr.arpa. (42)
10:53:16.689876 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 255.255.255.255.in-addr.arpa. (46)
10:53:16.799783 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 251.0.0.224.in-addr.arpa. (42)
10:53:18.578477 IP dom0.local.bootps > dnsdhcp.xxx.hu.bootps: BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44 (oui Unknown), length 300
10:53:18.689885 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 0.0.0.0.in-addr.arpa. (38)
10:53:19.689859 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 0.0.0.0.in-addr.arpa. (38)
10:53:21.709822 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 0.0.0.0.in-addr.arpa. (38)
- A hozzászóláshoz be kell jelentkezni
annyit megint elértem, hogy a dhcp-server konfigjában kikapcsoltam az option domain-name-servers és az option domain-name opsönöket, így most megint látok dhcp-reply -ket a xenbr6 -os interfészen (ami a FW-ból a DHCP-server felé néz.)
- A hozzászóláshoz be kell jelentkezni
A jelenlegi felállás:
dom0:~# tcpdump -i xenbr6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xenbr6, link-type EN10MB (Ethernet), capture size 96 bytes
11:04:04.519760 arp who-has dnsdhcp.xxx.hu tell dom0.local
11:04:04.519906 arp reply dnsdhcp.xxx.hu is-at 00:16:3e:1a:34:a6 (oui Unknown)
11:04:04.519921 IP dom0.local.bootps > dnsdhcp.xxx.hu.bootps: BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44 (oui Unknown), length 300
11:04:04.520440 IP dnsdhcp.xxx.hu > 192.168.1.200: ICMP echo request, id 18622, seq 0, length 28
11:04:04.629833 IP dom0.local.mdns > 224.0.0.251.mdns: 0 [2q] PTR? 1.60.10.10.in-addr.arpa.[|domain]
11:04:04.630328 IP dom0.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain]
11:04:04.740014 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 200.1.168.192.in-addr.arpa. (44)
11:04:05.009943 IP dnsdhcp.xxx.hu.bootps > dom0.local.bootps: BOOTP/DHCP, Reply, length 300
11:04:05.639849 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 255.255.255.255.in-addr.arpa. (46)
11:04:05.749806 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 200.1.168.192.in-addr.arpa. (44)
11:04:07.521580 IP dom0.local.bootps > dnsdhcp.xxx.hu.bootps: BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44 (oui Unknown), length 300
11:04:07.521858 IP dnsdhcp.xxx.hu.bootps > dom0.local.bootps: BOOTP/DHCP, Reply, length 300
11:04:07.529785 IP dom0.local > dnsdhcp.xxx.hu: ICMP host 192.168.1.200 unreachable, length 56
11:04:07.649844 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 255.255.255.255.in-addr.arpa. (46)
11:04:07.759787 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 200.1.168.192.in-addr.arpa. (44)
11:04:09.639807 IP dom0.local.mdns > 224.0.0.251.mdns: 0 PTR? 0.0.0.0.in-addr.arpa. (38)
11:04:09.639941 arp who-has dom0.local tell dnsdhcp.xxx.hu
- A hozzászóláshoz be kell jelentkezni
"a FW -on az ip-forwarding és a masquerade be van kapcsolva."
Az nem lesz jó, ha nincs olyan NAT modul, ami ezt megfelelően kezelné. Ugyanis a szerver a giaddr mezőben található IP-re küldi vissza a csomagokat (jelen esetben úgy tűnik, hogy ez a 192.168.1.200, amit el is utasít ICMP host unreachable üzenettel).
Javaslat: a 192.168.1.200 felől jövő és a dnsdhcp.xxx.hu UDP/67-re tartó csomagokat vedd ki a NAT-ból.
RFC 3121:
"4.1 Constructing and sending DHCP messages
If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'."
- A hozzászóláshoz be kell jelentkezni
Ha kilövöm a natot iptables -F -el (semmilyen más szabály nem volt beállítva), a hiba akkor is ugyanez. Forwarding továbbra is 1 ugye. Pingek mennek.
- A hozzászóláshoz be kell jelentkezni
"Ha kilövöm a natot iptables -F -el"
iptables -t nat -F legyen.
Akkor nézzük meg részletesebben:
tcpdump -i xenbr6 -nvvv -s 1500 port 67 or icmp
- A hozzászóláshoz be kell jelentkezni
dom0:~# iptables -t nat -F
dom0:~# tcpdump -i xenbr6 -nvvv -s 1500 port 67 or icmp
tcpdump: listening on xenbr6, link-type EN10MB (Ethernet), capture size 1500 bytes
13:45:48.740621 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0x5d748d5, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
13:45:48.741712 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 48) 10.10.60.2 > 192.168.1.199: ICMP echo request, id 40125, seq 0, length 28
13:45:49.001742 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.2.67 > 192.168.1.254.67: [bad udp cksum 935e!] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x5d748d5, Flags [ none ] (0x0000)
Your-IP 192.168.1.199
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.10.60.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.1.254
13:45:51.749898 IP (tos 0xc0, ttl 64, id 48486, offset 0, flags [none], proto: ICMP (1), length: 76) 10.10.60.1 > 10.10.60.2: ICMP host 192.168.1.199 unreachable, length 56
IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: ICMP (1), length: 48) 10.10.60.2 > 192.168.1.199: ICMP echo request, id 40125, seq 0, length 28
13:45:53.746503 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0x5d748d5, secs 1280, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
13:45:53.746876 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.2.67 > 192.168.1.254.67: [bad udp cksum 9359!] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x5d748d5, secs 1280, Flags [ none ] (0x0000)
Your-IP 192.168.1.199
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.10.60.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.1.254
13:46:00.745875 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0x5d748d5, secs 3072, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
13:46:00.746262 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.2.67 > 192.168.1.254.67: [bad udp cksum 9352!] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x5d748d5, secs 3072, Flags [ none ] (0x0000)
Your-IP 192.168.1.199
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.10.60.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.1.254
13:46:16.749181 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0x5d748d5, secs 7168, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
13:46:16.749593 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.2.67 > 192.168.1.254.67: [bad udp cksum 9342!] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x5d748d5, secs 7168, Flags [ none ] (0x0000)
Your-IP 192.168.1.199
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.10.60.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.1.254
10 packets captured
10 packets received by filter
0 packets dropped by kernel
---------------------------------------------------------------------
dhcp:
subnet 10.10.60.0 netmask 255.255.255.0 {
}
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.200;
option subnet-mask 255.255.255.0;
#option domain-name-servers dnsdhcp.tilb.sze.hu;
#option domain-name "tilb.sze.hu";
option routers 192.168.1.254;
option broadcast-address 192.168.1.255;
}
a lan felé néző iface a 192.168.1.254
a dhcp eth0 -ja 10.10.60.2
a fw interfacéja ami a dhcp felé néz egy bridge: 10.10.60.1 -es ip -vel végződik a FW -ben. ezen van ugye a dhcp eth0 -ja is.
a fw -on csak az ip_forward van 1 -re kapcsolva.
- A hozzászóláshoz be kell jelentkezni
Tehát összefoglalva ezek ismétlődnek a kliens válasza nélkül:
DHCP Discover:
src: 10.10.60.1:67 dst: 10.10.60.2:67 giaddr: 192.168.1.254
DHCP Offer:
src: 10.10.60.2:67 dst: 192.168.1.254:67 giaddr: 192.168.1.254 yiaddr: 192.168.1.199
Kipróbáltam (nem XEN alatt), és szépen működik dhcp3-relay (dhcrelay3) és dhcp3-server (dhcpd3 v3.0.4) segítségével.
Csak ezek kellenek hozzá:
- 10.10.60.2-on a 192.168.1.0/24-re legyen route a 10.10.60.1 felé
- az INPUT láncban a DHCP szerver felé eső (xenbr6) interfészen be kell engedni a 192.168.1.254-re tartó UDP/67 csomagokat.
- a DHCP relay kliens felé eső intefészének IP-je (192.168.1.254) sehol ne legyen NAT-olva a DHCP szerverrel folytatott kommunikáció során
- A hozzászóláshoz be kell jelentkezni
találtam valamit:
Caution
Under some circumstances, UDP and/or TCP communication from a DomU won't work for no obvious reason. That happened with the lists domain in my setup. Looking at the IP traffic with tcpdump -nvvi eth1 in Dom0 showed that UDP packets from the lists DomU had incorrect checksums. That problem was corrected by arranging for the following command to be executed in the lists and test domains when the eth0 device was brought up:
ethtool -K eth0 tx off
- A hozzászóláshoz be kell jelentkezni
Ez érdekesen hangzik, és megmagyarázná azt is, hogy XEN nélkül miért megy probléma nélkül. Az a kérdés, hogy nálad beválik-e az ethtool használata, és elmúlik-e a "bad udp cksum".
- A hozzászóláshoz be kell jelentkezni
A bad UDP Checksum eltűnt, itt már más probléma lesz. Dumpoltam egy kört, látszólag a FW lan felé néző interfésze nem kapja meg a dhcp-reply -t:
TCPDUMP a dhcp eth0 -ján:
dnsdhcp:~# tcpdump -i eth0 -nvvv -s 1500 port 67 or icmp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
14:40:09.707868 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0xb6381c8, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
14:40:09.708454 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.2.67 > 192.168.1.254.67: [udp sum ok] BOOTP/DHCP, Reply, length 300, hops 1, xid 0xb6381c8, Flags [ none ] (0x0000)
Your-IP 192.168.1.200
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.10.60.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 11: "tilb.sze.hu"
Default-Gateway Option 3, length 4: 192.168.1.254
Domain-Name-Server Option 6, length 4: 10.10.60.2
14:40:13.711779 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0xb6381c8, secs 1024, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4
és ezt csinála egymás után.
TCPDUMP a FW xenbr6 -ján (dhcp-server felé néz):
dom0:~# tcpdump -i xenbr6 -nvvv -s 1500 port 67 or icmp
tcpdump: listening on xenbr6, link-type EN10MB (Ethernet), capture size 1500 bytes
15:40:09.707830 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0xb6381c8, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
15:40:09.708611 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.2.67 > 192.168.1.254.67: [udp sum ok] BOOTP/DHCP, Reply, length 300, hops 1, xid 0xb6381c8, Flags [ none ] (0x0000)
Your-IP 192.168.1.200
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.10.60.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 11: "tilb.sze.hu"
Default-Gateway Option 3, length 4: 192.168.1.254
Domain-Name-Server Option 6, length 4: 10.10.60.2
15:40:13.711732 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 10.10.60.1.67 > 10.10.60.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, hops 1, xid 0xb6381c8, secs 1024, Flags [ none ] (0x0000)
Gateway-IP 192.168.1.254
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
és így tovább ismétlődik.
Olyan mintha jó lenne, de az ip-t valamiért mégsem kapja meg a laptop. Ha a lan felé néző eth0 -t tcpdumpolom nem látom, hogy ideérne az IP.
dom0:~# tcpdump -i eth0 -nvvv -s 1500 port 67 or icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
15:45:20.159386 IP (tos 0x0, ttl 128, id 47947, offset 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, xid 0x860aa624, Flags [ none ] (0x0000)
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
15:45:24.183564 IP (tos 0x0, ttl 128, id 47950, offset 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, xid 0x860aa624, secs 1024, Flags [ none ] (0x0000)
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:0f:b0:4c:f4:44
Requested-IP Option 50, length 4: 169.254.207.183
Hostname Option 12, length 12: "KOCSISSANDOR"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Option 249, Vendor-Option
15:45:32.184734 IP (tos 0x0, ttl 128, id 47955, offset 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:b0:4c:f4:44, length 300, xid 0x860aa624, secs 3072, Flags [ none ] (0x0000)
Client-Ethernet-Address 00:0f:b0:4c:f4:44
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Érdekes...
- A hozzászóláshoz be kell jelentkezni
"a FW lan felé néző interfésze nem kapja meg a dhcp-reply -t"
Nem is kell látszania, ugyanis az a tűzfalnak szóló INPUT forgalom, ezért nem fogja kiküldeni az eth0-n. Az INPUT chain szabályait és a default policyt nézd meg a tűzfal DHCP szerver felé néző interfészén, illetve azt, hogy az eth0 is szerepel-e a DHCP relay interfészei között (ha nincs kitöltve, az is jó).
- A hozzászóláshoz be kell jelentkezni
"illetve azt, hogy az eth0 is szerepel-e a DHCP relay interfészei között (ha nincs kitöltve, az is jó)."
eth0 volt ott.
Kivettem, nem írtam oda interfészt és így működik. Nemtudom mikor postoltam az elsőt ide a fórumba, de reggel 8 óta küzdök vele. Itt valószínűleg a xen és a xen interfészei miatt volt a gebasz. Ugyanis az eth0 vif0.0 -ként kapcsolódik a dom0 -ba ez végződik a xen által alapértelmezetten létrehozott xenbr0 -ra, amire pedig a peth0 csatlakozik (physical eth0). Ezeket bár mindet kipróbáltam, nem voltak jók.
Itt egy link ezekről az interfészekről ha nem lenne világos:
http://man.chinaunix.net/network/shorewall-docs-html-3.0.8/images/Xen1…
Nem tudom melyik interfésznévvel lenne jó, de nekem így tökéletesen megfelel. Esetleg hogyan lehet ezt lenyomozni?
- A hozzászóláshoz be kell jelentkezni
Jah, komolyan mondom ilyen segítséget nem mindennap kap az ember. Örök hála érte! ;)
- A hozzászóláshoz be kell jelentkezni
"eth0 volt ott."
Bocs, félrevezettelek, elírtam. A xenbr6-nak kellett volna ott lennie az eth0 mellett, vagy üresen kell hagyni. Tehát a DHCP relay agent csak akkor veszi fel a szerver felől érkező válaszcsomagot, ha a kliens interfészén túl a DHCP szerver felé néző interfészen is hallgat. Ha nem adsz neki interfészt, akkor automatikusan mindegyiken. Szerintem itt volt a titok nyitja.
- A hozzászóláshoz be kell jelentkezni