Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: rezervované jméno 10. 02. 2017, 21:19:59
-
Existuje v současnosti nějaká možnost jak zveřejnit zařízení ze sítě za několika NATy do internetu na nějaké veřejné (ideálně statické) IPv6 adrese? SixXs již nepřiděluje a alternativa (asi) není.
-
teredo
-
Existuje v současnosti nějaká možnost jak zveřejnit zařízení ze sítě za několika NATy do internetu na nějaké veřejné (ideálně statické) IPv6 adrese? SixXs již nepřiděluje a alternativa (asi) není.
nějaká komerční vpn?
-
https://tunnelbroker.net/
-
https://tunnelbroker.net/
to jsem zkoušel a nejde přes NAT. minimálně protože vyžaduje IPv4 endpoint "pingovatelný" a to můj provider neposkytuje.
-
HE (tunnelbrooker) nějakou dobu nabízel i PPTP tunely, ty fungovaly i přes x NATů, ale už to nedělá.
Tunel od nich funguje jen v přípdě NATu 1:1.
-
Mně to funguje i za normální maškarádou:
~ # ip a s eth0
...
26: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.0.126/24 brd 192.168.0.255 scope global eth0
...
~ # ip tunnel add he-ipv6 mode sit remote 216.66.86.122 local 192.168.0.126 ttl 255
~ # ip link set he-ipv6 up
~ # ip addr add 2001:470:6e:834::2/64 dev he-ipv6
~ # ip route add ::/0 dev he-ipv6
~ # ip -f inet6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
26: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::3285:a9ff:fe17:5dc8/64 scope link
valid_lft forever preferred_lft forever
34: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 state UNKNOWN qlen 1
inet6 2001:470:6e:834::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::c0a8:7e/64 scope link
valid_lft forever preferred_lft forever
~ # ping6 nix.cz
PING nix.cz(info.nix.cz (2a02:38::1001)) 56 data bytes
64 bytes from info.nix.cz (2a02:38::1001): icmp_seq=1 ttl=58 time=65.4 ms
-
to jsem zkoušel a nejde přes NAT. minimálně protože vyžaduje IPv4 endpoint "pingovatelný" a to můj provider neposkytuje.
Jako že to zemře čistě kvůli tomu, že tvůj provider zahazuje příchozí ICMP echo requesty? To je škoda…
-
Mně to funguje i za normální maškarádou:
Ano, pokud jsi za tou maškarádou sám, kdo použítá služeb HE a IPv6 pingem udržuješ otevřený NAT pro 6in4 tak to jede.
-
to jsem zkoušel a nejde přes NAT. minimálně protože vyžaduje IPv4 endpoint "pingovatelný" a to můj provider neposkytuje.
Jako že to zemře čistě kvůli tomu, že tvůj provider zahazuje příchozí ICMP echo requesty? To je škoda…
Nezemře to, jen se ten tunel vůbec nepodaří nakonfigurovat, protože oni odmítají vytvořit tunel jehož IPv4 endpoint jim neodpoví na ping. Škoda je hlavně používat providera který zahazuje jakékoliv pakety mířící ma mně přidělenou IP adresu.
-
U Forpsi Cloud lze mít VPS za 30 Kč měsíčně, v ceně je jedna IPv4 adresa a /64 blok IPv6 adres, to je slušná cena a VPS se dá využít i jinak.
Nemít ještě z minula SixXs tunel, šel bych touto cestou.
V čem ale nemám jasno je jaký typ tunelu a software pro jeho zprovoznění použít, aby to mělo co nejmenší overhead a aby instalace a konfigurace byla tak nějak rozumně složitá.
-
Mně to funguje i za normální maškarádou:
Ano, pokud jsi za tou maškarádou sám, kdo použítá služeb HE a IPv6 pingem udržuješ otevřený NAT pro 6in4 tak to jede.
Ale jen do doby než na chvíli přijdeš o spojení a ten tunel (s tvými IPv6 adresami) ti ukradne jiný uživatel za tím samým NATem a bude si ho taky udržovat IPv6 pingem. Je to loterie kterou nelze doporučit, jediné rozumné použití v případě nutného NATu (kde není k dispozici více veřejných IPv4 adres) je buď staticky směrovat IPv4 pakety s protokolem 42 na jednu pevnou vnitřní IPv4 adresu, nebo ten tunel ukončit přímo na tom zařízení kde je NAT a dovnitř už normálně routovat IPv6.
-
U Forpsi Cloud lze mít VPS za 30 Kč měsíčně, v ceně je jedna IPv4 adresa a /64 blok IPv6 adres, to je slušná cena a VPS se dá využít i jinak.
Nemít ještě z minula SixXs tunel, šel bych touto cestou.
V čem ale nemám jasno je jaký typ tunelu a software pro jeho zprovoznění použít, aby to mělo co nejmenší overhead a aby instalace a konfigurace byla tak nějak rozumně složitá.
Jde použít třeba libovolné tunelování které umí balit ethernetové rámce do IPv4 UDP paktetů, já mám vyzkoušené vtund. Na VPS se pak spustí radvd ohlašující ten IPv6 blok /64 do toho tunelovaného ethernetu, na protistraně taky vtund a ten tunelovaný ethernet spojit do bridge s lokálním ethernetem. Když tunel nepojede, nebude přicházet ani ohlašování IPv6 od radvd a lokální klienti se automaticky přepnou na používání IPv4.
-
Je nutné to tunelovat i s Ethernetem? Proč do IPv4 paketu nenacpat rovnou IPv6 paket?
A adresa z toho /64 bloku je přidělena na eth0 toho VPS. Je v tomto případě správné a vůbec možné tunelovat celé /64? Tunelovat celé /64 v podstatě ani nepotřebuju.
Já bych na potenciálním konci toho tunelu měl veřejnou dynamickou IPv4 adresu, tedy nemusím řešit průchod NATem.
Asi by se dal použít nějaký běžný VPN software, ale nejsem si jist, jestli je to optimální řešení a jestli to není kanón na vrabce.
Vzhledem k tomu v jakém režimu nyní funguje SixXs chci být připraven na situaci, že to vypnou úplně nebo že Ignum vypne český POP.
Jinak na obou koncích tunelu bych měl Ubuntu 16.04.
-
Je nutné to tunelovat i s Ethernetem? Proč do IPv4 paketu nenacpat rovnou IPv6 paket?
Možná abys mohl mít IPv6 adresu i na té VPS když máš jenom jednu /64?
Já bych klidně použil tu OpenVPN.
-
Dotaz: Lze v domací (Mikrotik) síti používat IPv6 (only) i bez (stabilního) připojení?
Jde o to, že pokud mi vypadne internet, pořád bych chtěl aby mi fungovala alespoň lokální síť.
-
Jak lokální adresy (fe80), tak adresy přidělené RA běžícím na Mikrotiku, budou dál normálně fungovat.
-
Dotaz: Lze v domací (Mikrotik) síti používat IPv6 (only) i bez (stabilního) připojení?
Jde o to, že pokud mi vypadne internet, pořád bych chtěl aby mi fungovala alespoň lokální síť.
Možnos je vygenerovat si ULA (unique local address fc00::/7) prefix o velikosti /48, který používám pořad stejně v rámci vnitřní sít a vedle něj paralelně nějaký globální dle toho, co mám od ISP aktuálně přiděleno. Lokální zařízení tak mám pořád stjně na stejných ULA adresách a jen provoz ven na globálních.
Čístý IPv6 only provoz v domácí síti je relaticně smutný, pokud je podpořen NAT64, tak dnes realativně OK (sám to tk mám), poku nemám doma věci, co jsou vyloženě IPv4 only.
-
Tak jsem teda rozchodil teredo. na http://nic.cz mi ve frirefoxu svítí u IPv6 zelená, v Chromiu červená :D a když se přes http://www.ipv6proxy.net/ na tu adresu podívám, tak to i funguje. Ještě nevím proč mi ale nejde, když mám 2 zařízení s teredy, tak se navzájem nepingnou (ani ten server) nejede i přestože ping z internetu (http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-ping.php) na oba jde a oba můžou pingnout ipv6.google.com.
-
Protože přímá komunikace mezi dvěmi teredo konci funguje kapánek jinak, než při teredo-zbytek IPv6 světa. Záleží na typu NATu, za kterými jsou klienti, protože dva Teredo klienti snaží bavit přímo mezi sebou přes ty svoje NATy (Teredo server se použije jen pro otevření UDP portu v NATu a Teredo relay se nepoužívá).
A situace se ještě výrazně komplikuje, pokud oba Teredo konce jsou za stejným NATem, ale nejsou ve stejném LAN segmentu (pokud jsou velde sebe na LAN, tak se mají nají přes multicast a bavit se přímo), zde bývá totální smůla.
-
Je nutné to tunelovat i s Ethernetem? Proč do IPv4 paketu nenacpat rovnou IPv6 paket?
Pokud máte jen /64 tak ethernet umožní jednu z těch adres nechat rovnou na VPS (a zároveň to bude default gateway pro domácí síť) a na protistraně použít bridge. Navíc to umožní spustit na VPS radvd což zajistí že při delší nedostupnosti VPS všichni klienti v domácí síti automaticky mohou přestat používat globální IPv6 adresu což povede k tomu že budou do internetu komunikovat přes IPv4 (neboli nebudou odříznutí od dual-stack serverů).
A adresa z toho /64 bloku je přidělena na eth0 toho VPS. Je v tomto případě správné a vůbec možné tunelovat celé /64? Tunelovat celé /64 v podstatě ani nepotřebuju.
Spousta lidí si myslí že v IPv6 můžou fungovat i s užšími podsítěmi než /64, ale zadělávají si tím na problémy - viz např. https://tools.ietf.org/html/rfc5375#section-3
Pokud by navíc u eth0 na VPS byla sirší maska než /64 (třeba /56) tak bude potřeba pořešit odpovědi na neighbor solicitation, rozhodně ne tak že VPS bude odpovídat že má všechny adresy z /64 (to by vedlo na přeplňování tabulky na default gateway poskytovatele VPS) ale buď to nakonfigurovat ručně jen pro používané IPv6 adresy v domácí síti (to je otrava a navíc to nefunguje s privacy extensions které například Android vyžaduje) nebo použít něco jako ndppd s "iface tap0" což do tap0 (to je ten ethernetový tunel) bude neighbor solicitation přeposílat.