Over drafput

Nog een nieuwtje. Als ik router_2 en router_3 (de andere, niet gelijkaardige router) achter router_1 hang (die dus een /60 prefix krijgt) en op router_2 en router_3 instel om een /61, /62 of /63 aan te vragen, krijgen die dat ook zonder problemen. Ik begin te vermoeden dat het hier om Telenet-shenanigans gaat... ... Meer weergeven

@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 😛  ... Meer weergeven

@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 😛   ... Meer weergeven

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. ... Meer weergeven

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. ... Meer weergeven

@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. ... Meer weergeven

@NofanTasi Dit is de interface-pagina van de TP-link:   En dit is die van de privé-router:  ... Meer weergeven

@Arnie  schreef:   Als ik je overzichtje per router en interface bekijk vraag ik me echter af of de TP-link routers het IPv6 verkeer misschien niet gewoon bridgen, ipv routeren. Ik ben dan ook erg dom geweest en heb tweemaal de foto van de TP-Link geplaatst [facepalm]... DIT is de interface van de privé router:  ... Meer weergeven

Ik heb vandaag nog eens geprobeerd om de kotbazen te overtuigen om die instelling in de "mijn-telenet" te wijzigen, maar dat is helaas een doodlopend straatje. De oplossingen die daar op steunen, zullen dus al niet lukken. Mijn privé-router houd ik liefst in de ketting. Niet omdat ik hier niet rond zou kunnen werken, maar vooral omdat dergelijke opstellingen relatief vaak voorkomen. Dit topic zou dus meteen als naslag kunnen dienen voor zij die op hetzelfde probleem stuiten, maar NIET dezelfde luxe hebben om zonder die tweede router te kunnen werken (voor welke reden dat ook moge zijn). Maar dan nu, tromgeroffel... HET WERKT! Wel, soort van. We zijn in de buurt. Ik kan SSH'en van het open internet naar mijn lokale server (dit heb ik getest door te SSH'en naar een VPS over 4G en dan daarmee SSH'en naar de lokale server). Dit heb ik bereikt door op beide routers een traffic-rule in de firewall in te geven die TCP-trafiek op poort 22 forward van de WAN-zone naar de LAN-zone. Ook het updaten van DDNS-records werkt al perfect (door gewoon met een python-scriptje mijn Cloudflare-DNS te updaten). Dit zijn nu de interfaces van de TP-link: En dit zijn de interfaces van de privé-router: Beide WANs zijn gewoon ingesteld op DHCPv6 (zoals die default zijn). Het was dus gewoon de firewall die alles tegenhield. Ik had dit aanvankelijk al verwacht en had het firewall-proces op beide routers al eens gestopt tijdens mijn eerste poging. Nu ben ik erachter gekomen dat wanneer je dat doet, er mogelijk ergens in de programma-stack iets fout gaat, want de router dropt dan gewoonweg alle verbindingen. Je moet effectief een regel toevoegen die alle trafiek doorlaat als dat je doel is. Ik heb na de succesvolle SSH-test een traffic-rule gemaakt die alle verbindingen toelaat van en naar mijn router's IPv6-adres. Dit met het idee dat ik dan in de toekomst gewoon alles op mijn privé-router kan regelen. Het enige probleem dat dan overblijft, is dat wanneer de DHCPv6-lease van de TP-link update, het adres van de privé-router en al diens clients ook potentieel veranderen. De DDNS zorgt er dan wel voor dat alles bereikbaar blijft (dat heb ik al kunnen testen), maar het adres dat staat opgegeven als destination in de trafic-rule van de TP-link's firewall (de rule die alle trafiek doorsluist naar mijn privé-router) zou dan niet meer kloppen. Ik heb al geprobeerd of ik het ULA-adres (met statische prefix) niet kon gebruiken in de firewall-rule, maar dat lijkt niet te werken.  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? Dan zouden er later ook nog andere studenten een eigen router kunnen plaatsen en meteen ook van buitenaf kunnen verbinden. Ik ga er dan wel van uit dat PD enkel bij routers, hypervisors en andere hoogtechnische zaken gebeurd, en dat er dus niet perongeluk een leek met zijn iPhone buiten de firewall zou kunnen komen te vallen. Zit ik hier fout in mijn begrip van PD? Is zo'n regel maken überhaupt mogelijk? I have questions. Hopefully you have answers. ... Meer weergeven

Het gaat dus wel degelijk om een CV8560E en die is inderdaad wit (er hangt een zwarte CH6643E naast die de bovenburen van internet voorziet, vandaar de verwarring). De TP-Link is een TL-WR2543ND met OpenWrt 19.07. Het IPv4-lan adres van deze is 192.168.1.1/24.   Mijn privé-router is een Linksys WRT1200AC, ook met OpenWrt 19.07. Het IPv4-lan adres van deze is 192.168.5.1/24. De TP-link's WAN is ingesteld als DHCPv6 client en krijgt een /64 en een /128 adres (beide met 2a02:... vooraan) en een /60 PD. Mijn privé router krijgt op zijn beurt (ook met DHCPv6) twéé /64 adressen en twéé /128 adressen (telkens één globaal met 2a02:.. vooraan en één ULA met fdxx:... vooraan) en een /62 PD. (als u even weet te vertellen wat ik best wegkras uit de beelden, kan een foto plaatsen van het interface-overzicht in OpenWrt, dat lijkt me duidelijker dan alles proberen uit te leggen.) Alle netwerk-apparaten achter mijn privé-router krijgen vervolgens een hele hoop IPv6 adressen (mede door IPv6 privacy-mode op linux, vermoed ik), maar de apparaten lijken allemaal zeker één globaal IPv6-adres te krijgen met 2a02:... vooraan. Ze kunnen ook allemaal op internet zonder problemen, maar ik slaag er niet in om ze van over het internet te pingen, ssh'en of wat dan ook. ... Meer weergeven

Ik heb toch nog maar eens gekeken of ik het dan niet simpeler kan oplossen met IPv4. Het probleem waar ik dan meteen op stuit is dat de TP-Link router een IPv4-adres van de vorm 191.168.0.x/24 krijgt, terwijl mijn gedetecteerd publiek adres (met IPchicken) ééntje in het verwachte formaat van 84.194.x.x is. Dit zou, voor zover ik weet, op CGN wijzen, wat meteen mijn doel onhaalbaar maakt. Is dat correct?  ... Meer weergeven

Latency is het voornaamste, maar niet het enige probleem. Sommige spelers klagen over packet-loss en de verbinding over de tunnel valt soms gewoon helemaal weg (we hebben dan ook flink moet goochelen om het überhaupt werkend te krijgen). Het feit dat iedereen nog extra software moet installeren om met de server te verbinden is ook een pijnpunt.  De RTT naar de server door de WireGuard-tunnel (die over de VPS loopt) is nu vaak meer dan 200ms met her en der packet loss en wegvallende verbindingen. Voorheen, toen we nog servers konden hosten op de universiteit, was dit hooguit een twintigtal milliseconden met een directe, stabiele verbinding. Dit is dan ook het scenario waar we terug naartoe willen.  Ik keek meteen naar IPv6 omdat ik er van uitging dat elk apparaat automatisch een routeerbaar globaal adres kreeg en dat ik dus met een DDNS het gewenste resultaat kon bereiken (zonder wakker te moeten liggen over port-forwarding, NAT, etc. ) Anderzijds dacht ik ook dat er meteen genoeg ruimte was in het door Telenet toegewezen netwerk-segment om mijn privé-router een appart subnetje toe te wijzen zonder al teveel moeite. Assumpties die, nu blijkt, niet correct waren.  ... Meer weergeven