iptables en internet

[bobby022]

static IP, Installatie netwerk, PXE
eth0 = 10.0.0.15

Gateway/DNS = 10.0.0.1

DHCP IP, Internet only
eth1 = DHCP

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.1 0.0.0.0 UG 107 0 0 eth1
0.0.0.0 10.0.0.1 0.0.0.0 UG 108 0 0 eth0
10.0.0.0 0.0.0.0 255.255.0.0 U 108 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 107 0 0 eth1

Beide nic's kunnen 8.8.8.8 berijken.
eth0 werkt als PXE netwerk, maar krijgt geen Internet door.

sudo iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Zou moeten werken, maar Internet blijft nog steeds onbereikbaar.

Ik heb dit moeten doen adhv een script die door een collega opgezet is,
die geeft nu de schuld aan Ubuntu en updates.
(normaal werk dit script wel, maar dit betreft een VM op Hyper-V)

Het zal iets simpels zijn, maar ik heb even geen idee meer waar

[bobby022]

De inhoud van de rules.v4 file:

# Generated by iptables-save v1.8.4 on Tue Oct 10 11:17:09 2023
*nat
:PREROUTING ACCEPT [32:4700]
:INPUT ACCEPT [3:210]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth1 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE << Mijn laatste aanpassing
COMMIT
# Completed on Tue Oct 10 11:17:09 2023
# Generated by iptables-save v1.8.4 on Tue Oct 10 11:17:09 2023
*filter
:INPUT ACCEPT [*cijfers*]
:FORWARD ACCEPT [*cijfers*]
:OUTPUT ACCEPT [*cijfers*]
COMMIT
# Completed on Tue Oct 10 11:17:09 2023

[EverLast2002]

Wat is het resultaat van :

ping www.google.nl
dig www.google.nl

Ik zie dat je 8.8.8.8 probeert, maar werkt DNS wel?

[bobby022]

EverLast2002 schreef op woensdag 11 oktober 2023 @ 10:52:
Wat is het resultaat van :

ping www.google.nl
dig www.google.nl

Ik zie dat je 8.8.8.8 probeert, maar werkt DNS wel?

PING www.google.nl (*.*.*.*) 56(84) bytes of data.
64 bytes from bc-in-f94.*.net ((*.*.*.*)): icmp_seq=1 ttl=57 time=23.6 ms
64 bytes from bc-in-f94.*.net ((*.*.*.*)): icmp_seq=2 ttl=57 time=21.3 ms
64 bytes from bc-in-f94.*.net ((*.*.*.*)): icmp_seq=3 ttl=57 time=21.8 ms
^Z
[25]+ Stopped ping www.google.nl
admin2@IPXE:~$ dig www.google.nl

; <<>> DiG 9.16.1-Ubuntu <<>> www.google.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22085
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.google.nl. IN A

;; ANSWER SECTION:
www.google.nl. 283 IN A (*.*.*.*)

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Oct 11 06:02:25 EDT 2023
;; MSG SIZE rcvd: 58


(*.*.*.*) = IP, en deze is hetzelfde.
het 'dig' command is mij nieuw, maar als ik dit goed lees werkt deze dus ook.

[EverLast2002]

"normaal werk dit script wel, maar dit betreft een VM op Hyper-V"

- wat is 'normaal' in jouw situatie, gebruik je dan juist geen hypervisor of wel maar op een ander platform (ESXi) ?
- kun je een standaard Ubuntu vm maken (zonder dat script) en daarmee testen vanuit Hyper-V ?

[DataGhost]

En waarom haal je zo panisch de IP's uit de output weg? Zo is nog niet te zien of je toevallig een extreem rare configuratie draait.

Forwarding moet je overigens ook met sysctl aanzetten, gewoon een iptables-regel is niet genoeg.

[ Voor 29% gewijzigd door DataGhost op 11-10-2023 15:37 ]

[PLeX]

DataGhost schreef op woensdag 11 oktober 2023 @ 15:33:
En waarom haal je zo panisch de IP's uit de output weg? Zo is nog niet te zien of je toevallig een extreem rare configuratie draait.

En waarom maskeer je....

[DataGhost]

PLeX schreef op woensdag 11 oktober 2023 @ 15:35:
[...]


En waarom maskeer je....

....?

[PLeX]

DataGhost schreef op woensdag 11 oktober 2023 @ 15:36:
[...]

....?

Ondanks dat ik 't verhaal niet direct helemaal weet te doorgronden vind ik "panisch" niet een gepaste reactie, vandaar de suggestie het anders te bewoorden.

[EverLast2002]

Ik kan me niet voorstellen dat dit gaat helpen, omdat je zegt dat het script altijd heeft gewerkt.
Ik heb in 1 van mijn Gateways deze regel staan:

# Allow established sessions to receive traffic:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

[bobby022]

DataGhost schreef op woensdag 11 oktober 2023 @ 15:33:
En waarom haal je zo panisch de IP's uit de output weg? Zo is nog niet te zien of je toevallig een extreem rare configuratie draait.

Forwarding moet je overigens ook met sysctl aanzetten, gewoon een iptables-regel is niet genoeg.

Ik haal panisch het IP adres weg omdat dit van een klant van ons is.
En ik geen zin heb in evt issues met management óf de klant zelf als dit opeens gevonden word.
want die zijn nogal GDPR hell-bend momenteel.

Daarom heb ik alleen de IP verwijderd, en verder niets.
Ik snap dat het erger word als ik nog meer ga verwijderen

[bobby022]

EverLast2002 schreef op woensdag 11 oktober 2023 @ 15:50:
Ik kan me niet voorstellen dat dit gaat helpen, omdat je zegt dat het script altijd heeft gewerkt.
Ik heb in 1 van mijn Gateways deze regel staan:

# Allow established sessions to receive traffic:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Met altijd heeft gewerkt, bedoelde ik, gewoon op een bare-metal machine.
Maar nu heeft mijn Sales persoon dit in mn mik gedrukt, met de bewoording van, 'wij fixen ook jou custom omgeving'.

Met nu dus als dilemma, een netwerk waar geen tot weinig info over is, een VM die binnen een Hyper-V netwerk meedraait.

TV werk wel.
PXE werkt na de dubbele masquerade wel

Alleen het normale internet werkt nog niet.
en dat wilt de klant nu als windows update functie gaan gebruiken.

Maar ik zal even kijken naar je toegevoegde regel, hoop dat dat het was

[DataGhost]

Maar, vind je het zelf dan ook niet raar dat www.google.nl kennelijk naar het IP van een klant van je resolvet? Of is Google die klant? Oftewel: dat lijkt dus een fout in je systeem te zijn, en een goede plek om te gaan beginnen met troubleshooten.

Verder kan je met een IP-adres niet zo heel veel, tenzij je kennelijk dingen zonder enige firewall/auth aan het internet hebt hangen. Maar in dat geval wordt datzelfde adres al tientallen keren per dag bezocht door allerlei geautomatiseerde bots op zoek naar lekke software en daar gaat het al dan niet posten ervan op een techforum niet veel aan veranderen. En over het algemeen zijn IP's die op wat voor manier dan ook uit een DNS-resolver komen rollen naar aanleiding van een query op een TLD sowieso bedoeld om internet-facing te zijn dus dan is het nogmaals niet erg dat gewoon te posten.

[ Voor 22% gewijzigd door DataGhost op 11-10-2023 16:48 ]

[EverLast2002]

"Met nu dus als dilemma, een netwerk waar geen tot weinig info over is, een VM die binnen een Hyper-V netwerk meedraait."

- is er vanuit die Hyper-V omgeving uberhaupt wel een route naar het internet mogelijk,
of is daar ook te weinig info over?
nevermind...

[ Voor 4% gewijzigd door EverLast2002 op 11-10-2023 16:58 ]

[EverLast2002]

DataGhost schreef op woensdag 11 oktober 2023 @ 16:45:
Maar, vind je het zelf dan ook niet raar dat www.google.nl kennelijk naar het IP van een klant van je resolvet? Of is Google die klant? Oftewel: dat lijkt dus een fout in je systeem te zijn, en een goede plek om te gaan beginnen met troubleshooten.

Verder kan je met een IP-adres niet zo heel veel, tenzij je kennelijk dingen zonder enige firewall/auth aan het internet hebt hangen. Maar in dat geval wordt datzelfde adres al tientallen keren per dag bezocht door allerlei geautomatiseerde bots op zoek naar lekke software en daar gaat het al dan niet posten ervan op een techforum niet veel aan veranderen. En over het algemeen zijn IP's die op wat voor manier dan ook uit een DNS-resolver komen rollen naar aanleiding van een query op een TLD sowieso bedoeld om internet-facing te zijn dus dan is het nogmaals niet erg dat gewoon te posten.

Volgens mij resolved ie toch naar Google?
Laat ik het anders stellen : hoe zie jij dat ie niet naar Google resolved.. (oprechte nieuwsgierigheid)

[DataGhost]

EverLast2002 schreef op woensdag 11 oktober 2023 @ 16:56:
[...]


Volgens mij resolved ie toch naar Google?
Laat ik het anders stellen : hoe zie jij dat ie niet naar Google resolved.. (oprechte nieuwsgierigheid)

Omdat hij dat zelf zegt?

bobby022 schreef op woensdag 11 oktober 2023 @ 16:40:
[...]


Ik haal panisch het IP adres weg omdat dit van een klant van ons is.

Maar inderdaad, dat is anders (zonder die vraag+reactie) voor ons onzichtbaar, en verbergt daarmee een mogelijke oorzaak.

[ Voor 11% gewijzigd door DataGhost op 11-10-2023 17:01 ]

[bobby022]

EverLast2002 schreef op woensdag 11 oktober 2023 @ 16:53:
"Met nu dus als dilemma, een netwerk waar geen tot weinig info over is, een VM die binnen een Hyper-V netwerk meedraait."

- is er vanuit die Hyper-V omgeving uberhaupt wel een route naar het internet mogelijk,
of is daar ook te weinig info over?

dat is dus waarom ik het niet snap.
want Firefox (in dit geval) kan wel gewoon op internet komen vanuit diezelfde VM.

daarom dacht ik dat het aan de iptables lag, omdat ik die forward met Internet op eth0 > eth1
thands, op de baremetal machines werkt het.

Ik snap dat het eigenlijk geen verschil zou moeten maken of ik een VM en Baremetal heb.

*het enige wat ik vanuit de klant meekreeg is dat het een DNS was in onze VM, en of wij deze toe kunnen voegen. (10.0.0.15) > ipadres van de PXE nic.

en dat is zon beetje alles wat we weten over de omgeving.
Want ik zag ook een 3gb nic, maar die was niet bonded werd mij verteld, want de VM ziet dat als 1 verbinding.

[EverLast2002]

ik heb nog een tip voor je :

- check/modify this file : /etc/sysctl.conf, and remove bracket from line "net.ipv4.ip_forward = 1"
- save with : # sysctl -p

(volgens mij werd dit al door iemand hier gemeld)

[bobby022]

EverLast2002 schreef op woensdag 11 oktober 2023 @ 17:08:
ik heb nog een tip voor je :

- check/modify this file : /etc/sysctl.conf, and remove bracket from line "net.ipv4.ip_forward = 1"
- save with : # sysctl -p

(volgens mij werd dit al door iemand hier gemeld)

ja klopt, die had ik bekeken, en deze staat er netjes in.
was alleen vergeten te melden, mijn excuus

[EverLast2002]

Maar wat is nu precies je vraag/probleem, want ik begin er steeds minder van te snappen....
(zal wel aan mij liggen).

[Will_M]

EverLast2002 schreef op woensdag 11 oktober 2023 @ 17:17:
Maar wat is nu precies je vraag/probleem, want ik begin er steeds minder van te snappen....
(zal wel aan mij liggen).

Ligt echt niet aan jou. Ik snap er als netwerkbeheerder zijnde ook niet veel (meer) van

[EverLast2002]

Will_M schreef op woensdag 11 oktober 2023 @ 17:22:
[...]


Ligt niet aan jou. Ik snap er als netwerkbeheerder zijnde ook niet veel van

Gelukkig, dan ben ik niet de enige...
Ik zit wel momenteel snotverkouden incl verhoging op de bank dit topic door te spitten.
Valt niet mee

[bobby022]

EverLast2002 schreef op woensdag 11 oktober 2023 @ 17:24:
[...]


Gelukkig, dan ben ik niet de enige...
Ik zit wel momenteel snotverkouden incl verhoging op de bank dit topic door te spitten.
Valt niet mee

Dan kunnen wij met zn 3en elkaar een hand geven, want dit is precies waar ik meezit.

De opsomming zoals het bij mij nu binnenkomt.

Ik heb 2 netwerkpoorten.

eth0 > 10.0.0.15, PXE - werkend

IP: 10.0.0.15
Netmask: 255.255.0.0
Gateway: 10.0.0.1
DNS: 10.0.0.1

eth1 > DHCP, Internet - werkend, met firefox
IP: DHCP
gevonden settings:

IP: 192.168.10.70
Default route: 192.168.10.1
DNS: 192.168.10.11 192.168.10.0


Wanneer een client boot van eth0 werkt de PXE wel.
Maar er is geen internet verbinding die nodig is voor licentieactivatie. (eth1)

Klant wou DNS aangepast hebben, eth1 > 10.0.0.1, want er kwam opeens een windowsupdate verzoek bij.

De licenties worden netjes opgehaald, maar de WU website is blijkbaar onbereikbaar vanaf de PXE-client.


:vent: helaas zit de klant in de US, want ik heb het idee dat ik niet alles meekrijg over het 'netwerk' wat er loopt.

[DataGhost]

Waarom ben je dan op een server aan het troubleshooten en niet op de PXE client zelf? Of missen we nog steeds informatie? Wat voor IP/GW/DNS krijgt die PXE client? Wat is de 10.0.0.1 machine voor iets?

Welke machines hebben we het precies over? Client A, Server B, Gateway C en D, ....? Welke machine heeft internet nodig en krijgt dat niet, hoe zit die aangesloten tov de rest? Dat soort dingen.

[ Voor 43% gewijzigd door DataGhost op 11-10-2023 17:52 ]

[EverLast2002]

Oke, je hebt 1 vm met daarin 2 netwerkinterfaces.
eth0 en eth1 kunnen, elk apart, hun weg richting internet vinden.

Om jouw doelstelling te halen zal er een onderlinge route (communicatie) gemaakt moeten worden, tussen eth0 en eth1.
De vraag is of dat wenselijk is, met het oog op veiligheid. En ook de vraag waarom die vm in eerste instantie zo is geconfigureerd met 2 aparte netwerken.
Als je de route tabel bekijkt in je openingspost zie je dat er geen onderlinge communicatie is tussen eth0 en eth1.