Dotaz: Dostupnost služby www za modemem LTE

[grossaci]

Přílohy:

• IP_debi.txt (3674 bytů)
• IP_misak.txt (261 bytů)
• server.conf (1330 bytů)
• client.conf (569 bytů)

Dobrý den obracím se na Vás s prosbou pomoc. Předně musím podotknout, že nejsem znalý v oboru, pouze mám z netu a různých fór obecné povědomí. Bez hlubších znalostí jednotlivých oblastí mě unikají souvislosti. Prosím o nějaký "polopatický" návod.

Předmět zájmu. Chci postavit vlastní VPN síť pro spojení dvou PC. PC_1 má veřejnou dynamickou IP 1.2.3.4 . PC_2 LTE modem. Představuji si dostupnost PC_2 z Internetu na kterém je WWWW server, voláním mé veřejné adresy PC_1 a protunelováním do PC_2. Doposud jsem používal VPN třetí strany NGROK.

Zatím mám nainstalované OpenVPN server a klient, PING prochází z PC_1 server na PC_2 klient a opačně. Z PC_2 při spuštěném VPN má dosah na veřejný Internet. Nevím jak docílit "předání" brány lokání sítě 192.168.0.1 VPN serveru, aby bylo možno se z Internetu dostat na PC_2 v tunelu. Na PC_1 serveru je zapnuto předávání net.ipv4.ip_forward = 1. PC_1 a 2 v iptables momentálně všechny tabulky (filter, nat, mangle) ACCEPT.

PC_1 debian, server OpenVPN v lokalni síti 192.168.0.0/24 za modem/routerem ISP UPC s veřejnou dynamickou adresou 1.2.3.4 . IP debian 192.168.0.199, brána 192.168.0.1 PC_2 misak, klient OpenVPN připojený přes LTE modem

---

---

Odpovědi

[grossaci]

PC_1 debian, server OpenVPN v lokalni síti 192.168.0.0/24 za modem/routerem  
ISP UPC s veřejnou dynamickou adresou 1.2.3.4 . IP debian 192.168.0.199, brána 192.168.0.1
petr@debian:~$ ip r s
default via 192.168.0.1 dev enp1s0
10.9.8.0/24 via 10.9.8.2 dev tun0
10.9.8.2 dev tun0 proto kernel scope link src 10.9.8.1
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.199

PC_2 misak, klient OpenVPN připojený přes LTE modem
misak@misak:~$ ip r s
default via 192.168.42.129 dev enp0s29f7u6 proto dhcp metric 100
10.9.8.1 via 10.9.8.5 dev tun0
10.9.8.5 dev tun0 proto kernel scope link src 10.9.8.6
192.168.42.0/24 dev enp0s29f7u6 proto kernel scope link src 192.168.42.226 metric 100

server.conf PC_1
# vychozi port
port 1194
# vychozi protokol
proto udp
# sitove rozhrani
dev tun0
# zapne rezim TLS jako server <overovani>
tls-server
# soubory certifkatu
ca      /etc/openvpn/ca.crt    # vygenerovany certifikat
cert    /etc/openvpn/server.crt
key     /etc/openvpn/server.key  # soukromy klic k serverovemu certifikatu - tajny
dh      /etc/openvpn/dh2048.pem
# omezeni prav pod kterym bezi OpenVPN
user nobody
group nogroup
# uspornejsi pridelovani adres / zatim nevim
;topology subnet
# rozsah adres pro VPN - prvni adresu obsadi server (asi 10.9.8.1), ostaní IP pro klienty
server 10.9.8.0 255.255.255.0  # interní IP adresa tun0 10.9.8.1
# nevim co to je
;push "10.9.8.0 255.255.255.0"
;push "redirect-gateway def1 bypss-dhcp"
# klientovi se naridi, aby veškerou komunikaci presmeroval
# pres VPN, a parametr def1 zajisti neodstraneni puvodni brany
;push "redirect-gateway def1"
# predani zaznamu o DNS
push "dhcp-option DNS 213.46.172.38"
;push "dhcp-option DNS 213.46.172.39"
# udrzeni spojeni - kazdych 10s / restart po 120s nedostupnosti
keepalive 10 120
# komprese dat, je treba zapnout i na klientovi
comp-lzo
# to zajistuje udrzeni klicu v pameti po restartu spojeni
persist-key
persist-tun
# zapnuti logovani
status /etc/openvpn/log/openvpn-status.log
# ukecanost zápisu do logu (minimalni)
verb 3

klient.conf PC_2
# nastaveni chovani klient
client
# jmeno typ sitoveho rozhrani
dev tun0
# vychozi port
port 1194
# vychozi protokol
proto udp
# IP adresa serveru VPN + protokol
remote 1.2.3.4 1194
# pouziti dynamickeho cisla portu pro VPN tunel
nobind
# omezeni prav pro beh OpenVPN
user nobody
group nogroup
# certifikaty
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key
# zapnuti komprese prenosu a musi byt zapnuta i na serveru
comp-lzo
# to zarucuje udrzeni klicu v pameti pri restartu spojeni
persist-key
persist-tun
# ukecanost logu
verb 3

[X]

Představuji si dostupnost PC_2 z Internetu na kterém je WWWW server, voláním mé veřejné adresy PC_1 a protunelováním do PC_2.

HTTP/HTTPS postupne odnatujes az do cile. Z UPC routeru na PC1 a z PC1 tunelem na PC2.

[grossaci]

Nemohl by si to bíže specifikovat? Zkoušel jsem nějaká iptables pravidla , ale zamotal jsem se v tom. Mysím že zpáteční paket při průchodu tun -> eth na stroji PC_2 na kterém je server VPN, nedostane bránu domácí sítě 192.168.0.1, aby mohl projít zpět do Internetu.

[grossaci]

Promiň, má tam být PC_1.

[grossaci]

Děkuji, pokusím se tím "prokousat". Myslel jsem si že by to takto mělo jít, ale nevěnoval jsem tomu dostatečnou pozornost. Místo toho jsem se opět obracel na konfiguraci Open VPN, na routování atp.

[X]

Staci si predstavit celou cestu paketu. Nejprve dorazi na UPC router a musi se dostat na PC1 = prvni DNAT portu 80/443 v rozhrani modemu na 192.168.0.199(PC1). Paket dorazi na PC1, zde je druhy DNAT a je preposlan na druhy konec tunelu na 10.9.8.5(PC2). No a tady v lepsim pripade posloucha ten web.

Muzou nastat dva problemy. Web na PC2 neposloucha na vsech rozhranich. To lze vyresit snadno. Vetsi problem je, ze zdrojova adresa paketu, ktery prisel tunelem je verejna, ale PC2 ma do tunelu nastaveno jen 10.9.8.0/24 a nevi, ze ho tam ma vratit. Takze, bud muzu na PC2 do tunelu poslat vsechno 'push redirect-gateway', nebo predem na PC1 zamaskuji zdrojovou adresu = SNAT.

Poznamka: Kazdy paket ma zdrojovou adresu a cilovou adresu. Cilova adresa ze pouzva pro smer "tam" a zdrojova pro smer "zpet". Pomoci DNAT/SNAT mechanismu muzes transparetne zdrojovou, nebo cilovou adresu zamaskovat. Nastuduj si to..

[Jendа]

Vetsi problem je, ze zdrojova adresa paketu, ktery prisel tunelem je verejna, ale PC2 ma do tunelu nastaveno jen 10.9.8.0/24 a nevi, ze ho tam ma vratit. Takze, bud muzu na PC2 do tunelu poslat vsechno 'push redirect-gateway', nebo predem na PC1 zamaskuji zdrojovou adresu = SNAT.

Třetí možnost, kterou volím já, je na toto se vykašlat a použít přepojování spojení v user-space. Pro jednoduché služby pomocí socatu (ukazuji níže), pro weby používám haproxy - výhoda pak je, že může běžet víc webů na jedné IP adrese, a taky tam dělám TLS terminaci pro „hloupá“ zařízení.

[Jendа]

Zatím mám nainstalované OpenVPN server a klient, PING prochází z PC_1 server na PC_2 klient a opačně.

Skvěle, teď bych:

• Vyzkoušel, že z PC_1 prochází i HTTP na PC_2 (dovnitř VPN) - tj. spustil na něm prohlížeč (může to být třeba links, pokud tam není grafické rozhraní) a navštívil http://10.9.8.6/ (nebo jakou že má ve VPN adresu PC_2 ve VPN).
• Spustil na PC_1 socat TCP4-LISTEN:8040,reuseaddr,fork "TCP4:10.9.8.6:80". Tím se web stane přístupným z internetu na http://1.2.3.4:8040/.
• Až ti toto bude fungovat, přikročíme k tomu, aby byl web dostupný na standardním portu a aby tam bylo HTTPS.

Nevím jak docílit "předání" brány lokání sítě 192.168.0.1 VPN serveru, aby bylo možno se z Internetu dostat na PC_2 v tunelu.

Nic takového není potřeba, brána v tomto vůbec nefiguruje.

Do budoucna by bylo dobré nastavit adresu klienta v OpenVPN napevno, myslím, že není garantováno, že se nezmění. Dělá se to pomocí client-config-dir /etc/openvpn/ccd v konfiguraci server. Do toho adresáře se následně umístí soubor s jménem klienta (tak jak je napsáno v certifikátu) a do něj se napíše ifconfig-push 10.9.8.6 10.9.8.1.

[grossaci]

Děkuji za návrh řešení, zatím se pokusím pohnout s vědomostmi o iptables viz předchozí návrh. Váš návrh řešení si nechám v záloze, neboť mám testovací sestavu, kde si to všechno mohu odzkoušet. Ostrý provoz je zatím přes NGROK.

[grossaci]

Včera jsem se dostal na řešení se socatem. Velice mě překvapila okamžitá funkčnost tohoto řešení. Navíc zapadlo do mé koncepce. Jedna instance socat pro WWW server, po předání příslušného portu do vnitří sítě je PC2 přístupný z Inernetu, druhá instance pak vzálená správa SSH na mnou definovaném portu, přístupný jen z vnitřní sítě.

Ještě jednou děkuji za nápad funkčního řešení.

[Andrej]

1. IPv6. Nemá smysl se dál zabývat se experimentem z roku 1975, který měl omylem 32-bitové adresy a totálně selhal. Doporučuji ty „hlubší znalosti“ načerpat o současném internetu, tedy IPv6.
2. Protokol pro VPN se jmenuje IPSec. Software pro výměnu klíčů a nastavení IPSec se jmenuje například StrongSwan. (OpenVPN je častý omyl, protože to má VPN v názvu; ve skutečnosti jde o jednovláknovou dětskou hračku.)

[k3dAR]

ten "experint" se ale od te doby bezne pouziva, naproti tomu IPv6 za 25let sve existence se stale o rozsireni snazi

[trekker.dk]

OT: ISP údajně poskytuje IPv6 a včera jsem se konečně dokopal k tomu zjistit, proč mi u DNS resolveru tak dlouho trvá, než se dočkám odpovědi - tj. ověřit, že za to může IPv6. A jo, od ISP chodí RA s prefixem o velikosti /64, Linux si jako výchozí bránu nastaví link-local adresu routeru (což je asi v pořádku), jako zdrojová adresa IPv6 paketů se použije link-local adresa WAN rozhraní (to už mi moc v pořádku nepřijde.) Výsledkem je, že IPv6 nefunguje - rozhodně ne ve výchozím nastavení.

To už radši ten funkční prý-experiment (když je přidělení statického aspoň /56 prefixu ze strany ISP nemožné)

[Andrej]

A jo, od ISP chodí RA s prefixem o velikosti /64…

Možná je takového ISP potřeba kopnout do prdele. Normální je /48, maximálně /56. Dostat /64 je skoro k hovnu. (Hodně štěstí při uschopňování Androidu, který schválně nepodporuje DHCPv6, na něčem takovém.)

Nebo taky možná ne. Možná je chyba mezi židlí a klávesnicí. Například můj ISP posílá RA o rozsahu /64, které vede do místní sítě ISP (ve které jsou vidět routery). Standard. Nicméně jakmile se člověk rozhlédne trochu podrobněji kolem, konkrétně pomocí DHCPv6 prefix delegation (IA_PD), najednou dostane úplně jiný /48 rozsah, do kterého ISP routuje (skrz tu adresu z /64 rozsahu, kterou domácí router tak nějak má, ale většinou ji až tolik nevyužije, protože nejčastěji používá pro hop k poskytovateli link-local adresy).

Linux si jako výchozí bránu nastaví link-local adresu routeru (což je asi v pořádku)…

Ano, to je v pořádku.

…⁢jako zdrojová adresa IPv6 paketů se použije link-local adresa WAN rozhraní…

Tak to je hodně špatně. Ale otázka je, jaký má být očekávaný výsledek, pokud se ISP chová naprosto hloupě a nestandardně a celé podsíti (která má dostat asi tak /48) přidělí /64. To je potom každá rada drahá a může se stát asi tak cokoliv. Nebo si uživatel nepřečetl dokumentaci k tomu, jak získat (kromě jednotlivé adresy pro router samotný) taky rozsah k routování do vnitřní sítě?

Každopádně je dobré podívat se v ip addr show na typy a růné flagy adres. Tam se člověk obvykle dočte, proč se která adresa (ne)volí jako odchozí.

[trekker.dk]

Slovo normální má ve světě, ve kterém žijeme - i když v něm zřejmě nežijete vy - určitý význam. Velice zjednodušeně takový, že je to běžné, nejčastěji se vyskytující. Dostat od ISP /56 nebo dokonce /48 normální není.

Nicméně jakmile se člověk rozhlédne trochu podrobněji kolem, konkrétně pomocí DHCPv6 prefix delegation...

...nedostane žádnou odpověď

[Aleš Kapica]

Bourku, To ten tvůj svět není normální. Se s tim smiř.

[trekker.dk]

A jéje, soudruh komunista kapicabot taky ještě nemá naučeno, co znamená slovo normální.

[Andrej]

…nedostane žádnou odpověď…

Tak zavolá poskytovateli a vyjasní si to, ne? Není mu 5 let, aby takový „problém“ nedokázal vyřešit, ne?

[trekker.dk]

Šlo by to? Jistě? Je důvod tomu věnovat čas na úkor něčeho jiného? Není. IPv6 je v domácích podmínkách momentálně "nice to have", ale to je tak vše, připojení k internetu přes IPv4 bohatě stačí

[Andrej]

…připojení k internetu přes IPv4 bohatě stačí

Prdlajs. IPv4 není internet.

[trekker.dk]

To je věc interpretace a slovíčkaření, ale každopádně ať už si vymyslíte jakékoliv slovíčko, pro domácí použití to bohatě stačí.

[Andrej]

Tak to nevím. Já ho běžně nepoužívám. Ve vnitřní síti dokonce vůbec.

[grossaci]

V běžné případě by to bylo řešení, ale jak jsem již v úvodu nastínil, připojení je realizováno LTE modemem (T-mobile). Tady s IPv6 moc nepochodím.

[Peter Golis]

Skús sa opýtať Andreja aké argumenty máš použiť aby si dostal verejný IPv6 rozsah pre LTE (mobil alebo modem) a koľko je podľa neho akceptovateľná cena za takú službu.

[Andrej]

…aké argumenty máš použiť aby si dostal verejný IPv6 rozsah pre LTE…

Letopočet.

…a koľko je podľa neho akceptovateľná cena za takú službu.

Nula.

[Peter Golis]

Tak prečo nejdeš príkladom a neposkytuješ taký internet pre širokú verejnosť ty? Ostatní sa radi pridajú, keďže ich prinúti konkurenčný tlak. Ak o to teda bude záujem.

[Andrej]

Tak prečo nejdeš príkladom a neposkytuješ taký internet pre širokú verejnosť ty?

Proč bych to dělal? Mám mnohem zajímavější zaměstnání. Kromě toho, můj poskytovatel něco takového bravurně zvládá. Proč bych mu chtěl konkurovat? Jedině bych si vylámal zuby.

[Peter Golis]

Požadovať zdarma, to áno. Ale tvoriť už nie. To je zaujímavé zamestnanie. Koľko platia? Pridal by som sa.

[Andrej]

Plácáš kraviny.

Co rozumíš pod pojmem zdarma? Tvrdíš, že mému poskytovateli neplatím? To by mě asi odpojil, ne?

Proč bych „tvořil“ něco, co je už dávno vytvořené, například IPv6?

Koľko platia? Pridal by som sa.

Ano, přidej se. Proti tomu nikdo nic nemá.

[Peter Golis]

Toto sú veľmi pekné a výstižné otázky, ale skús si na ne odpovedať sám. Tieto tvoje otázky totižto presne vystihli tvoje požiadavky.

[Andrej]

Tak já si na ně odpovím:

• Platím svému poskytovateli řádný roční paušál.
• Můj poskytovatel mi dává /48 rozsah.

Ano, obojí je přesně v souladu s mými požadavky.

Nějaké další dotazy?

[Peter Golis]

Tak máš produkt ktorý ti vyhovuje. Drž sa ho.

Ale ber do úvahy že iní ľuďia majú iné potreby, a vyhovuje im niečo iné. Takže nútiť im riešenie tvojích potrieb je mimo realitu.

[Andrej]

Kdyby někomu fakt vyhovnoval IPv4, asi by netrávil čas psaním dotazů do poradny, že jo.

[Peter Golis]

A kde je v pôvodnej otázke vidíš IPv6?

To už by si mohol použiť IPv6 aj ako odpoveď na otázku: ako uvariť guláš. Tiež to bude odveci odpoveď na otázku ktorú nechápeš.

[Andrej]

A kde je v pôvodnej otázke vidíš IPv6?

Proč přesně bych ho tam měl vidět? Co zase bereš?

Tiež to bude odveci odpoveď na otázku ktorú nechápeš.

Mně zase přijde, že zatímco já otázku typu „potřebuju IPv6, ale nedochází mi to“ spolehlivě rozeznám a chápu (a odpovídám na ni) už asi tak 15 let nebo víc, ty zkrátka nechápeš vůbec nic, jako například která bije, která je tohle planeta atd. atp. Klasika.

[Peter Golis]

IPv6 ≠ 42