Help deze kotstudent zijn MC-server lokaal te hosten.

[drafput]

Ik zal meteen ter zake komen. Onze netwerk-situatie is als volgt: We hebben hier op kot een HGW van Telenet (zo'n zwarte doos met pinkende lampjes) die in MAC-passthrough staat (dat kon de Telenet-technieker mij vertellen) met daarachter een TP-Link router met OpenWrt op. Deze router wordt dan via een switch verder verdeeld naar alle kamers. Vanzelfsprekend heb ik geen toegang tot de instellingen op die HGW, maar de instellingen van de TP-Link router kan ik wel wijzigen als het niets te ingrijpend is.
Op mijn kamer (achter die TP-link router dus) heb ik mijn eigen privé-router aangesloten waar ik volledige toegang toe heb.

Nu heb ik ooit vanop mijn privé-router met WireGuard een tunnel gemaakt naar een VPS om vanop de campus een ssh-verbinding naar mijn PC te kunnen aanleggen. Deze oplossing blijkt echter net iets teveel latency te hebben om een bruikbare Minecraft-server te hosten, bovenop het feit dat ik aan al mijn speelkammeraadjes WireGuard moet uitleggen, met alles wat daarbij komt kijken. 
Mits de centjes dezer dagen ook niet uit de lucht komen gevallen en VPS'en niet gratis zijn (of zoals recent is gebleken, gewoon in vlammen kunnen opgaan), zou ik liefst mijn lokale server dus gewoon toegankelijk maken over het open internet (desnoods met een DDNS ofzo).

De reeds genoemde Telenet-technieker zei dat een IPv4-oplossing afgeschreven was zonder toegang tot de HGW-instellingen. Ik zit nu dus al een dag of drie te prutsten met IPv6-instellingen, maar verder dan een /56 prefix delegation te krijgen op de wan-interface van de TP-link router, ben ik nog niet gekomen. Ik lijk zelfs de wan-poort van de TP-link router niet te kunnen pingen? Zelf vindt ik maar bitterweinig terug over hoe Telenet alles regelt binnen hun netwerk, en soms zelfs tegenstrijdige informatie.

Ten einde raad, hoop ik dat de Netweters ons uit ons lijden kunnen verlossen. We staan open voor alle sugesties! 🙂

[NofanTasi]

---

@drafput  schreef:

[...]
Zou het dan bijvoorbeeld mogelijk zijn om op de TP-Link een traffic rule aan te maken die alle trafiek doorlaat naar alle adressen die een /62 prefix-delegation ontvangen?

---

---

Goede vraag. Ik vrees misschien van niet voor een dynamisch IP abonnement. Zoals je zegt, als de :dddd: in de /60 prefix verandert moeten hard gecodeerde destinations in trafic-rules ook veranderen. Maar: gaat het overigens over extra/custom (ip6tables?) gecodeerde destinations? Ik vraag het omdat OpenWRT firewall GUI forwarding/traffic regels tussen zones laat specifieren. Of de implementatie van die regels zich dynamisch aanpast als die zones van adres range veranderen, dat weet ik niet. Ik heb een vast IP abonnement en jouw situatie doet zich bij mij dus nooit voor.

[Arnie]

Met openwrt heb ik niet veel ervaring. Bij een fritzbox is het inderdaad wel mogelijk de firewall rules te definieren op basis van het hosts gedeelte van het IPv6 address, prefix onafhankelijk.  De rule blijft dus keurig werken, ook als de prefix veranderd.

Bij de UDM pro is dat niet het geval. Daar dien je de volledige IPv6 adressen te gebruiken voor een firewall rule. Als de prefix zou veranderen (voor mijn nog niet gebeurd), dan moet je dus ook de rule aanpassen.

[drafput]

@NofanTasi Dit is de interface-pagina van de TP-link:

En dit is die van de privé-router: 

[drafput]

@NofanTasi @Arnie Ik heb al redelijk diep gegraven in de werking van de firewall in OpenWrt. Ik ben ook even in de broncode gaan snollen nadat ik ergens op deze commit ben gebotst.

Ik heb de beschreven notatie al even getest en het is dus wel degelijk mogelijk om een regel te maken voor een specifiek adres, onafhankelijk van de aangeleverde prefix. Ik kan dus alvast een dergelijke regel instellen op mijn privé router en die naar mijn server laten wijzen. Ik heb diens IPv6 al als static lease ingesteld in de instellingen van de privé-router. Ik moet alleen nog eens nakijken of dergelijke reservaties ook rekening houden met wijzigende prefixes. Zoniet, is er dan een manier in odhcpd om een IPv6 assignment-range in te stellen? (in OpenWrt worden IPv4 adressen onder de x.x.x.100 bijvoorbeeld niet toegekend, maar ik vind geen instelling in de GUI om dat bij IPv6 te doen)

Ik moet nog kijken of ik het op de TP-Link ingesteld krijg om alles door te laten naar adressen in de vorm van <60-bit ontvangen prefix><2 gedelegeerde prefix bits><66 overblijvende bits>.

Zou ik ervan uit mogen gaan dat;
    a) als een router een /62 delegate uitdeelt, hij dan ook geen adressen meer uitdeelt aan reguliere DHCPv6 clients in heel die range.
    b) een router standaard het eerste "subnet" (ergo, dat met alle resterende bits in het netwerk-gedeelte op 0) in het verkregen delegate voor zich houd om DHCPv6 clients in te plaatsen?

Zoja, kan ik misschien nog wel wat goochelen met IP-tables om het gewenste gedrag te bekomen.

[drafput]

Correctie: Dit is de commit-message die ik bedoelde. De link in mijn vorige reactie brengt je naar de broncode die de regels parset uit wat wordt doorgegeven via de GUI.

[NofanTasi]

cool ! proficiat met commit vondst. Door willekeurige (niet noodzakelijk prefix, niet noodzakelijk continue) bitmasks toe te laten in GUI, en die rechtstreeks naar ip(6)tables te vertalen, kan men, kennelijk, inderdaad, per prefix delegatie mask, en/of per host bits, firewall regels configureren. Zelf heb ik zulks nog nooit nodig gehad, of geprobeerd, maar het is erg goed om weten. Ik wens je er alleszins veel success ermee. Hou ons op de hoogte. Mijn commentaar op je uitganspunten (a) en (b) is (maar ik heb geen documentatie hierover gezocht) beiden positief. Ook dank om de delegatie :dddd: masks van beide router's LAN en WAN expliciet te tonen. De, bijvoorbeeld, TP-Link router LAN neemt een adress met volle mask (/60 in dit geval) dat de router gedelegeerd krijgt (e.g. :0410: /60) en binnen eerste subnet (0) dat de router zelf delegeert. Kennelijk heeft je volgende router in de ketting niet datzelfde (0) subnet (hij heeft :0414: /62).

[drafput]

Ik heb ondertussen de TP-link ingesteld om altijd een /60 prefix aan te vragen, en de privé-router om op zijn beurt een /62 prefix aan te vragen (met het idee dat als de ze op "automatic" bleven staan, ze ooit misschien eens een grotere prefix te pakken zouden krijgen en dan zou de firewall-rule niet meer kloppen). Dit is trouwens de regel die ik uiteindelijk heb toegevoegd aan de firewall van de TP-link:

Deze zal dus alle trafiek die binnenkomt in de WAN-zone (waar de IPv6 WAN-interface in zit) doorlaten indien deze bestemd is voor een adres dat één (of meer) van de opgegeven IP/mask regels matcht.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                    Telenet prefix                     +-+-+-+-+
|                                                       | A | B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                        interface ID                           +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Als we er even de indeling van een IPv6-adres bijnemen, zien we dat het masker dat ik gebruik in de regel (0:0:0:c::) enkel de 2 bits in veld A matchen. Mits dit de eerste twee bits zijn die volgen op de /60 prefix die de CV8560E aan de TP-link delegeert, veronderstel ik dat de waarde van veld A op 0b00 staat wanneer een pakket bestemd is aan een rechtstreeks verbonden host. Wanneer dit veld echter 0b01, 0b10 of 0b11 is, veronderstel ik dat het betreffende pakket bestemd is voor een host in een gedelegeerde /62 prefix, en laat ik het door.

Ziet iemand hier kwalijke fouten in betreffende security?

Het veld B, dat uit de laatste 2 bits van het IPv6 network-ID veld bestaat, kan trouwens ook door mijn privé-router gebruikt worden om het achterliggende netwerk nog eens in 4 sub-netwerken op te splitsen. Ik heb van deze mogelijkheid gebruik gemaakt om mijn servers op een aparte VLAN te zetten en enkel naar het subnet op die vlan inkomende trafiek door te laten. Zo kan ik de firewall van de (V)LAN waar al mijn "gewone" apparaten op zitten, gewoon ongewijzigd laten.

Alles lijkt momenteel te werken. Het is de vraag of dit effectief een veilige en langdurige oplossing is die resteert.

[drafput]

---

@drafput  schreef:

Als we er even de indeling van een IPv6-adres bijnemen...

---

Wel, ASCII-art vindt hij precies niet zo leuk... Dan maar met een foto 😛

[Ex-Netweter]

---

@drafput  schreef:

Ik heb ondertussen de TP-link ingesteld om altijd een /60 prefix aan te vragen, en de privé-router om op zijn beurt een /62 prefix aan te vragen (met het idee dat als de ze op "automatic" bleven staan, ze ooit misschien eens een grotere prefix te pakken zouden krijgen en dan zou de firewall-rule niet meer kloppen).

---

Dat eerste is niet nodig. Deze instelling wordt door de CV8560E gewoon genegeerd.

De achterliggende router krijgt (op dit ogenblik) altijd een /60 prefix (wat je ook aanvraagt).

Er zijn blijkbaar wel plannen bij Telenet, om in de toekomst één /57 toe te kennen via PD.

[NofanTasi]

Ik kan me grondig vergissen. Het gaat, denk ik, niet om '32 bit', maar, wel om '16 bit' :dddd: en, meerbepaald, de laatste 4 bits AB van de laatste d, namelijk: bits 60 61 62 63 van het IPv6 destinatie traffic adres/mask (als men van meest significante bit 0 begint). Nu, vermits je router :0414: op LAN heeft en 0004&000c=0004 gaat de regel 0:0:0:4::/0:0:0:c::, in zijn eentje, alle verkeer naar jouw router, matchen, voor jouw kamer deel B. Dus werkt je kamer en zijn router nu wel degelijk. Je kan dit eventueel checken met 'ipv6tables -L -nv' (#pkts #bytes). De twee andere regels 0:0:0:8::/0:0:0:c:: en 0:0:0:c::/0:0:0:c:: matchen in gemeenschappelijk deel A, maar, per kamer gaat het dus enkel om deel B. Andere kamers gaan, voor hun router, andere B hebben, pakweg, volgende kamer, :0415:. Nochtans: 0005&000c=0004 verschilt van 0005 (mismatch laatste bit 64), m.a.w. hun traffic heeft geen enkele match voor de gemeenschappelijke 3 regels. Nogmaals, ik kan me stevig vergissen, en: daarvoor sorry, maar ik denk dat je ::/0:0:0:3:: als enige regel nodig hebt (i.e. B=11), het is te zeggen: eender welke destinatie zolang de 'eigen-kamer' bits in B niet allen 0 zijn. Dat werkt voor alle kamers, voor alle kotstudenten met eigen-kamer-router. Je kan ook dit eventueel checken met 'ipv6tables -L -nv'. Beste @drafput , ik heb niets van dit alles effectief geprobeerd, dus: ik ratel misschien gewoon wat nonsense uit mijn nek, en, ik verontschuldig me dan ook, oprecht, voor het werk dat ik je, ongevraagd, mogelijk alzo in je schoenen schuif (zonder zelf iets te verifieren). Maar de algemene subnet match formule, die elke netwerk code best gebruikt, is merkwaardig eenvoudig, iets als: '(adres&mask)==network', voor eender welke (ook niet prefix of niet continue) betrokken bits.

[drafput]

---

@Ex-Netweter  schreef:

---

---

Dat eerste is niet nodig. Deze instelling wordt door de CV8560E gewoon genegeerd.

De achterliggende router krijgt (op dit ogenblik) altijd een /60 prefix (wat je ook aanvraagt).

Er zijn blijkbaar wel plannen bij Telenet, om in de toekomst één /57 toe te kennen via PD.

---

Het is net vanwege de "op dit ogenblik" dat we het maar vast hebben ingesteld. Eens dit achter de rug is, hoop ik er toch de komende 3 jaar niet meer mee te moeten knoeien 😛