InaLan: HowTo

**sv2flu** · 02-10-23, 17:23

Αρχικό μήνυμα από globalnoise

Μήπως, λέω μήπως καταλάθος, έχεις μπει με admin κωδικούς και έχεις κλείσει τα SIP στο router της Inalan?

Γιατί αυτή την εξυπνάδα την είχα κάνει και εγώ από συνήθεια και δεν έπαιζε το L2TP vpn που ήθελα.

Επίσης, μήπως το "myfritz" προσπαθεί να συνδεθεί στην διεύθυνση που βλέπει ως WAN? Που στη προκειμένη είναι η WAN-to-LAN εσωτερική; Κάνει public IP resolve?

Με την public IP σου δοκίμασες να συνδεθείς;

Για το ρούτερ της ιναλαν έχω μόνο κωδικούς user δεν μου έδωσαν admin και απο όσο διαβάζω δεν δίνουν. Το fritz έχει σελίδα που κανεις login στον λογαριασμό σου και εκεί σου εμφανίζει τις συσκευές σου. Καλά όλα μέχρι εκεί αλλά όταν επιλέγω το 7590 να το ανοίξω βγάζει connection timeout. Υποψιάζομαι ότι δεν βγαίνω από public ip γιατί όταν γράφω την ip μου δεν κάνει τίποτα. Στο myipaddress δείχνει ότι είναι η πραγματική μου ip. Πραγματικά σηκώνω τα χέρια ψηλά

**BillyVan** · 02-10-23, 18:09

Αν θελεις να κανεις DMZ μπορεις να δοκιμασεις να βαλεις στο ιδιιο δικτυο και το Φριτζ.

Δηλαδη στατικη ip στο ρουτερ της Ιναλαν πχ 192.168.1.1

DMZ απο το μενου που ειδες στην ip πχ Φριτζ 192.168.1.20 (η ip αυτη θα ειναι της WAN του Φριτζ)

Συνεχιζεις με το LAN δικτυο σου πχ dhcp server 192.168.2.1 και φυσικα ολες οι συσκευες σου θα παιρνουν 2.χχχ δικτυο.

Με ακριβως το ιδιο σεταπ ειμαι κι εγω

**Nikiforos** · 02-10-23, 19:30

Αρχικό μήνυμα από sv2flu

Ας γράψω και εγώ το πρόβλημα μου γιατι δεν βγάζω άκρη. Συνδέθηκα με inalan 1gbps, κουμπώνοντας στην lan1 το fritzbox 7590 στην wan. Όλα καλά, συνδέονται όλες οι συσκευές στο 7590 και το ρούτερ της inalan δίνει μόνο ίντερνετ τοπικά στο άλλο ρούτερ με το wifi κλειστό. Το πρόβλημα μου είναι ότι δεν μπορώ από το myfritz.com η με wireguard να συνδεθώ στο 7590 και επίσης σε ένα nas της synology ούτε εκεί μπορώ να συνδεθώ. Μίλησα με την εξυπηρέτηση, έκλεισαν το NAT αλλά μετά δεν είχα ίντερνετ οπότε το ξανά άνοιξαν. Τι κάνω, να βάλω static ip η block ip's;

καλησπερα, το καταργησαν το block ip, υπαρχει μονο στατικη 1 δλδ και παιζεις μονο με DMZ με δικο σου ρουτερ. Περιμενουμε τις αλλαγες που υποτιθεται οτι θα γινουν απο 1η Οκτ...

- - - Updated - - -

Αρχικό μήνυμα από ThReSh

Από σήμερα, λόγω του νέου κανονισμού της ΕΕΤΤ, αναγκάστηκαν.

https://inalan.gr/genikoi-oroi-update-1-10-23/

Στο άλλο topic γράφτηκε ότι δίνουν μάλλον αυτό https://support.huawei.com/enterpris...0m-pid-9028636

καλησπερα, τι θα αλλαξει δλδ? θα δινουν και bridge mode σε ολους αν θελουν??? ποιο ειναι το αλλο τοπικ? δινουν ONT????

- - - Updated - - -

εδω εγραψα? σορρυ μπερδευτηκα! καταλαβα για το αλλο οκ.

**Thanasakis11** · 10-10-23, 17:23

Σε περίπτωση που δεν έχει παρακολουθήσει κάποιος την "Οδύσσεια του IPv6" που ανέλυσα και προσπάθησα να λύσω με την βοήθεια κυρίως του globalnoise αλλά και άλλων παιδιών θα κάνω μια ανακεφαλαίωση.

Spoiler:

Επειδή το ζήτημα από τότε πάγωσε αποφάσισα να κάνω μερικές ακόμα δοκιμές μόνος μου μήπως και βγάλω άκρη. Εξάλλου όλη αυτή η ιστορία με το beta stage μου φαίνεται λίγο περίεργη. Ανάμεσα σε δοκιμές που έκανα ανακάλυψα πως αν κλείσω το ONT και το αφήσω κλειστό μέχρι να λήξει το prefix και το ξανασυνδέσω (όλα αυτά χωρίς να κλείσω το ρούτερ) καταφέρνει και παίρνει gua το ρούτερ. Το πρόβλημα του ότι δεν παίρνω default gateway συνεχίζεται αλλά είναι και αυτό πρόοδος. Σημειωτέον το γεγονός ότι μόλις λήξει ξανά το lease της IPv6 η καινούρια IP είναι πάλι ula και επιστρέφουμε στο μηδέν.

**buffos** · 11-10-23, 00:28

Αν δεν το έβαζες στην WAN, απλά έβαζες στο fritz να έχει σαν gateway την ip του ΖΤΕ? Υποθέτω οτι γίνετε.
Για αρχή βάλτο σε μια οποιδήποτε θύρα και δες οτι το βλέπει στο τοπικά δίκτυο. Μετά λύνεις και το θέμα του ιντερνετ.

**Thanasakis11** · 11-10-23, 10:03

Δυστυχώς δεν έχω το ZTE καθώς μου το αντικατέστησαν με το ONT.
Δοκίμασα όμως να βάλω το Fritz πίσω από γραμμή της Cosmote με IPv6 συνδεσιμότητα και λειτουργούσε κανονικά (πήρε address, default gateway και prefix για το LAN) άρα δεν είναι εκεί το θέμα.
Το θέμα όπως έχουν δείξει οι μέχρι στιγμής δοκιμές φαίνεται να είναι συστημικό της Inalan και μπορεί να έχει να κάνει με το authentication των χρηστών στο IPv6 μέρος του δικτύου της (εξού και η private ula που λαμβάνω καθώς και η διαφοροποιημένη συμπεριφορά ανάλογα με το διάστημα ανάμεσα στο GPON auth και το establishment της IP σύνδεσης).

Πολλά παιδιά εδώ στο φόρουμ έχουν επιβεβαιώσει σωστή λειτουργία του IPv6 σε bridge άρα το πρόβλημα δεν είναι γενικό και παρουσιάζεται τουλάχιστον στην περιοχή μου, δύσκολο να μαντέψω αν είμαι ο μόνος με αυτό το πρόβλημα ή όχι πάντως στο φόρουμ είμαι ο μόνος μέχρι στιγμής που το έχω αναφέρει.

**globalnoise** · 11-10-23, 10:13

Αρχικό μήνυμα από Thanasakis11

Όποιο ρούτερ και να βάλω (Fritz!Box, TP-Link, OpenWRT) παίρνει prefix, μία private ula address και δεν παίρνει default gateway

Παίρνει ULA? Χμμμμ

Κοίτα τι παίζει να γίνεται:

Όπως έδειξα εδώ οι WAN μας λαμβάνουν multicast traffic από τους "γείτονες".

Σε μένα, σκάνε από 2-3 router (ή συσκευές, δεν ξέρω) ICMPv6 packets με neighbor solicitation, neighbor advertisement, router advertisement.

Υπάρχει πιθανότητα να γίνεται το ίδιο και σε σένα, οπότε η WAN σου να τσιμπάει αυτό το router advertisement πρώτα, πριν φτάσει το router advertisement της Inalan σε σένα

Σε μένα όταν η WAN μου κάνει Router Solicitation σκάνε RA από κάτι Apple συσκευές (που θέλουν να μου δώσουν ULA) ένα Cisco router που δεν δίνει prefix information και κάτι κινέζικα router (Xiaomi μάλλον). Το edgerouter μου, τσιμπάει το DHCPv6-PD response που έχω ζητήσει και παίρνει το κανονικό GUA prefix να μοιράσει στο LAN μου*, αλλά ας πούμε τις προηγούμενες μέρες, για default gateway είχε την link-local του Cisco router.. Δούλευε κανονικά, αλλά το default gateway μου ήταν το Cisco router που επιβεβαίωσα οτι δεν είναι της Inalan. Rogue or not? Ποιος ξέρει..

*Μίλησα με Τ.Υ., με τον Γιώργο πάλι οπού του το ανέφερα αυτό και μου θα το κοιτάξει, μου είπε περί beta κλπ. Μου είπε επίσης αυτό που είχε πει σε σένα περί "υποστηρίζουμε μόνο SLAAC, και ας δουλεύει το DHCPv6". Στην ερώτηση μου, "μα πως θα πάρω prefix delegation χωρίς DHCPv6-PD? Το SLAAC θα δώσει μόνο στην WAN μια GUA" φάνηκε να έχει knowledge gap, οπότε μην το παίρνεις της μετρητοίς αυτό που σου είπε. Ακόμη και το δικό τους router από τη στιγμή που μοιράζει GUA στο LAN, με DHCPv6-PD πήρε το prefix. Για να 'χεις στο νου σου αν ρυθμίζεις κάτι, χρειάζεσαι DHCPv6-PD.

**Thanasakis11** · 11-10-23, 14:23

Ο Γιώργος σου είπε για SLAAC γιατί τα περισσότερα "χαζά" ρούτερ όπως το TP-Link και το Fritz κάνουν prefix delegation by default και σε βάζουν απλά να επιλέξεις τον τρόπο που θα πάρει gua το ίδιο το ρούτερ, άρα είτε έχουν συνηθίσει να το λένε έτσι για χάρην απλότητας είτε δεν ξέρουν και οι ίδιοι. Το TP-Link και με την SLAAC ρύθμιση που σου είχα δείξει PD κάνει για το LAN και μοιράζει addresses.

Τα δύο προβλήματα είναι η private ula που παίρνει το ρούτερ και η έλλειψη default gateway (= no route).

Αυτό που είπες για το multicast traffic είναι μεγάλο και μπορεί να εξηγεί τι κρύβεται πίσω από το πρόβλημα καθώς και γιατί δεν συμβαίνει σε όλους. Επιβεβαιώνει επίσης τις υποψίες μου περί ανετοιμότητας της Inalan για εφαρμογή του bridge (και διαλευκαίνει λίγο τα περί beta που μας πουλάει η TY).

- - - Updated - - -

Τα traceroute που ζήτησες για να μην μας σταυρώσουν στο κεντρικό νήμα:

Κώδικας:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  fritz.box (192.168.178.1)  0.347 ms  0.215 ms  0.216 ms
 2  x.x.x.254 (x.x.x.254)  1.239 ms  1.179 ms  0.907 ms
 3  10.0.6.11 (10.0.6.11)  1.414 ms  1.357 ms  1.281 ms
 4  10.0.6.102 (10.0.6.102)  17.971 ms  17.915 ms  17.860 ms
 5  * * *
 6  108.170.250.177 (108.170.250.177)  21.966 ms  22.148 ms  21.992 ms
 7  216.239.46.221 (216.239.46.221)  21.930 ms 209.85.248.179 (209.85.248.179)  21.853 ms 142.250.212.23 (142.250.212.23)  21.140 ms
 8  dns.google (8.8.8.8)  21.108 ms  20.972 ms  20.797 ms

Κώδικας:

traceroute to np-sof-02.cloudmatchbeta.nvidiagrid.net (80.84.175.137), 30 hops max, 60 byte packets
 1  fritz.box (192.168.178.1)  0.309 ms  0.231 ms  0.197 ms
 2  x.x.x.254 (x.x.x.254)  0.823 ms  0.707 ms  0.702 ms
 3  10.0.6.11 (10.0.6.11)  0.789 ms  1.303 ms  1.261 ms
 4  10.0.6.102 (10.0.6.102)  8.785 ms  8.444 ms  8.659 ms
 5  vivacom.bix.bg (193.169.198.162)  13.685 ms  13.622 ms  13.630 ms
 6  212-39-69-101.ip.btc-net.bg (212.39.69.101)  13.605 ms  13.705 ms 212-39-69-97.ip.btc-net.bg (212.39.69.97)  14.119 ms
 7  77-85-237-129.ip.ip.btc-net.bg (77.85.237.129)  54.720 ms  54.794 ms  54.660 ms
 8  77-85-237-130.ip.ip.btc-net.bg (77.85.237.130)  39.411 ms  39.296 ms  39.231 ms
 9  80.84.175.9 (80.84.175.9)  40.247 ms  40.286 ms  39.927 ms

**globalnoise** · 11-10-23, 18:51

Αρχικό μήνυμα από Thanasakis11

Ο Γιώργος σου είπε για SLAAC γιατί τα περισσότερα "χαζά" ρούτερ όπως το TP-Link και το Fritz κάνουν prefix delegation by default και σε βάζουν απλά να επιλέξεις τον τρόπο που θα πάρει gua το ίδιο το ρούτερ, άρα είτε έχουν συνηθίσει να το λένε έτσι για χάρην απλότητας είτε δεν ξέρουν και οι ίδιοι. Το TP-Link και με την SLAAC ρύθμιση που σου είχα δείξει PD κάνει για το LAN και μοιράζει addresses.

Ναι, αυτό παίζει σίγουρα.

Αρχικό μήνυμα από Thanasakis11

Τα δύο προβλήματα είναι η private ula που παίρνει το ρούτερ και η έλλειψη default gateway (= no route).

Αυτό που είπες για το multicast traffic είναι μεγάλο και μπορεί να εξηγεί τι κρύβεται πίσω από το πρόβλημα καθώς και γιατί δεν συμβαίνει σε όλους. Επιβεβαιώνει επίσης τις υποψίες μου περί ανετοιμότητας της Inalan για εφαρμογή του bridge (και διαλευκαίνει λίγο τα περί beta που μας πουλάει η TY).

Με ένα packet capture στην WAN θα λυνόντουσαν οι απορίες, αν ψηθείς για κανα EdgeRouter / ή MikroTik ποτέ

Τώρα τι μπορεί να κάνει η Inalan για αυτό δεν ξέρω. Υποθέτω οτι θα μπορούσαν να σετάρουν φιλτράρισμα αυτού του traffic (και γενικότερα multicast) στα ONT. Μόνο έτσι μπορώ να φανταστώ οτι θα μπορούσαν να περιορίσουν το να φτάνουν τέτοια πακέτα στις WAN μας. ~~Δεν ξέρω καν αν μπορώ στο EdgeRouter π.χ. να φιλτράρω σε ποια sources θα "ακούσει" για ICMPv6 configuration.~~ Όση ώρα το έγραφα σκέφτηκα οτι με firewall rules μπορεί να σεταριστεί κάτι τέτοιο. Θα το δοκιμάσω στην δική μου πλευρά κάποια στιγμή. Με κάτι τέτοιο filtering (αν είναι αυτό το θέμα) θα σεταριζόταν σωστά και στα δικά σου router. Το θέμα είναι, σου δίνουν τέτοιο firewall configuration capability? Να φιλτράρεις βάση icmpv6 πρωτόκολλο / code και να ορίσεις source mac address?

**Thanasakis11** · 11-10-23, 23:29

Έχω ήδη ψηθεί για MikroTik λόγω RouterOS και μάλλον θα πάρω το hap ax3 τους κάποια στιγμή (αν και είμαι ακόμα ανάμεσα σε αυτό και το GL-MT6000 της GL.iNet που έχει dual 2.5G ports και έρχεται με OpenWRT).
Προς το παρόν και χωρίς να έχω ψαχτεί πολύ με τα μενού του Fritz, τουλάχιστον στο κομμάτι του firewall, δεν βλέπω κάποιον σαφή τρόπο να φιλτράρω υπηρεσίες σε τέτοιο τεχνικό επίπεδο.
Η Inalan καλά θα κάνει μέσα στις επόμενες βδομάδες να βρει κάποιον τρόπο να φιλτράρει μόνη της τα πακέτα που ούτως ή άλλως δεν θα έπρεπε να λαμβάνουμε όλοι οι πελάτες στο δίκτυο. Διάβασα από τον x_undefined για ένα implementation της HCN με ARP Proxy άρα προφανώς υπάρχουν λύσεις για κάτι τέτοιο.

**x_undefined** · 12-10-23, 00:14

Η WAN IP που δίνει η Inalan είναι σε /22 subnet;

**Thanasakis11** · 12-10-23, 00:27

Όχι /24 είναι σε εμένα.

**x_undefined** · 12-10-23, 00:37

Οκ, εννοούσα βασικά κάτι μεγαλύτερο από /30. Άρα ναι, είναι «λογικό» που φτάνει broadcast κίνηση άλλων, αλλά όντως πρέπει να φιλτραριστεί από την Inalan με κάποιο τρόπο.

Έχω απορία ωστόσο αν φτάνουν πακέτα και από hosts εκτός του /24, αν το έχει ελέγξει κάποιος.

**globalnoise** · 12-10-23, 14:00

Αρχικό μήνυμα από x_undefined

Οκ, εννοούσα βασικά κάτι μεγαλύτερο από /30. Άρα ναι, είναι «λογικό» που φτάνει broadcast κίνηση άλλων, αλλά όντως πρέπει να φιλτραριστεί από την Inalan με κάποιο τρόπο.

Έχω απορία ωστόσο αν φτάνουν πακέτα και από hosts εκτός του /24, αν το έχει ελέγξει κάποιος.

Όχι, δεν έρχεται τίποτα από hosts εκτός του /24.

Και εμένα «λογικό» μου φαίνεται. ARP Proxy νομίζω τρέχει στον BRAS της (δεν έρχεται καθόλου ARP από άλλους παρά μόνο από αυτόν) αλλά αυτό πως θα περιόριζε τα multicast (είτε μιλάμε για IPv4 είτε για IPv6)?

Δεν νομίζω να υπάρχει τρόπος πέρα από firewalling. Στα δικά της router -> εύκολο. Στα δικά της ONT -> μάλλον? εύκολο (δεν είμαι σίγουρος). Αν όχι στα δικά της ONT -> στα δικά μας router -> σίγουρο, μιας και είναι ευθύνης μας.

Μην ξεχνάμε οτι το πρόβλημα έχει πηγή το λάθος configuration του χρήστη. Όλα αυτά τα multicast έρχονται από configurations χρηστών που έχουν κουμπώσει το ONT / Bridge τους σε LAN θύρα ή σε unfirewalled WAN.

Θέλω να τσεκάρω και την απόφαση 1058/11/2022 αν λέει κάτι σχετικά με ευθύνες του χρήστη προς την εταιρία σε τυχόν προβληματικό configuration / εξοπλισμό από πλευράς του.

**x_undefined** · 12-10-23, 14:56

Συμφωνώ ότι είναι από λάθος και άγνοια χρηστών, αλλά θα μπορούσε να είναι και σκόπιμα κακόβουλο. Το πιο λογικό θα ήταν η Inalan να προστατεύει τους υπόλοιπους συνδρομητές. Όντως δεν είναι ξεκάθαρο αν η ευθύνη αυτή πέφτει πλέον στον συνδρομητή, αλλά μου φαίνεται too much να το χρεώνεται αυτός ενώ θέλει απλώς να έχει ένα δικό του CPE. Μετά αλλάζουν τελείως και οι προϋποθέσεις που θα πρέπει να καλύπτει (δηλ. χρειάζεται πλέον σοβαρό router με customisable firewall). Θα το ψάξω κι εγώ περισσότερο, αν και πιστεύω ότι αυτά μπορούν (και πρέπει) να κόβονται από την Inalan.

Θέμα: InaLan: HowTo

Παρόμοια Θέματα

Inalan

INALAN στην Κυψέλη Αθήνα

Inalan στην Δυτική Θεσσαλονίκη

Inalan: Εντυπώσεις

Tags για αυτό το Θέμα

Bookmarks

Bookmarks

Δικαιώματα - Επιλογές