Jo, podle toho pingu je jediná možnost tunel
Máte ten mail strašně zmatený, některé adresy mají "a.a" a "b.b", jiné jsou v číslech, takže je v tom těžké se vyznat. Ale jestli to dobře chápu, tak stroj, který má veřejnou IP, má privátní IP 172.16.9.60 a u toho tunelu 10.0.0.1. Stroj, který nemá veřejnou IP, má privátní 172.16.0.27 a tunel 10.0.0.254. Pokud je to obráceně, tak si v následujícím textu budete muset IP přehazovat :-)
Taky by se hodil ten výpis routovacích tabulek, ale budu hádat, že na tom stroji bez veřejné adresy bude vypadat nějak takhle
10.0.0.0/24 dev tun0 default dev venet0 scope link
Jestli to tak je, tak máte pravdu - potřebujete mít jako default gateway IP adresu 10.0.0.1, ale když si tohle nastavíte jako default gateway, tak to nebude fungovat, protože přestane fungovat ten tunel
V takovém případě by řešení mělo být poměrně jednoduché, a sice nastavit pro tu IP adresu druhého konce tunelu samostatnou routu, tj.
172.16.9.60/32 dev venet0 default via 10.0.0.1
(Samozřejmě ponechat to 10.0.0.0/24 dev tun0, co se tam vyrobilo samo.)
Měnit zdrojovou IP adresu paketu pro ten NAT by mělo fungovat taky, ale je to horší řešení v tom, že se vám pak do všech logů bude zapisovat IP vaší vlastní VPS, to bych nedělal.
On 08. 05. 19 8:58, Pavel Hruška wrote:
Udělám souhrn, čím jsem teda prošel, napíšu k tomu svoje komentáře, pokud něco chápu špatně, klidně mě opravte. Začnu ale od konce reakcí na Tvůj poslední email:
ping-t 1 172.16.b.b => from 172.16.0.24 icmp_seq=1 Time to live exceeded
Ano, jediná možnost, jak se připojit, je přes konzoli VPS adminu.
Pravidlo prerouting s ohledem na veřejnou/privátní je následující iptables -t nat -A PREROUTING -d public.ip -p tcp -m tcp --match multiport --dports 222 -j DNAT --to-destination private.ip:22
U FORWARDU jsem pak dočasně povolil veškerý provoz, abych se někde nechytl (iptables -P FORWARD ACCEPT)
Traceroute mezi dvěma privátními adresami je takový (traceroute z 172.16.b.b.):
traceroute to 172.16.a.a (172.16.a.a), 30 hops max, 60 byte packets 1 172.16.0.27 (172.16.0.27) 0.095 ms 0.031 ms 0.049 ms 2 172.16.a.a (172.16.9.60) 0.311 ms 0.258 ms 0.254 ms
Takže to jde přes 172.16.0.27, podle mě, pokud změním default gateway, tak mi nikdy nic nebude fungovat, protože aby to fungovalo, pakety ve finále musí jít právě přes tu 172.16.0.27 (protože /32)??? Přes tu samou bránu mi jde provoz z té privátní VPSky taky do veřejného internetu.
Snažil jsem se včera udělat tunel
ip tunnel add tun0 mode gre remote 172.16.b.b local 172.16.a.a ip addr add 10.0.0.1/24 dev tun0 ...
Na druhé straně obdobně. Dokázal jsem si pingnout na druhou stranu tunelu, ale pokud jsem začal měnit bránu na té privátní VPS, nic nefungovalo, myslím, že kvůli tomu, co jsem psal dříve s ohledem na traceroute (zabalený paket ve finále musí někudy jít). Nebo se pletu?
Napadlo mě potom, že bych zkusil na výstupu NATu public VPS měnit source, aby se paket pak vracel přes tunel (10.0.0.1 je jeden konec tunelu, 10.0.0.254 druhý konec). Nevím, jestli to není blbost. Tady ale trošku plavu, omlouvám se, zkoušel jsem různě: -o tun0 -d 10.0.0.254
iptables -t nat -A POSTROUTING -d 10.0.0.254 -j SNAT --to-source 10.0.0.1 iptables -t nat -A POSTROUTING -d 10.0.0.254 -j MASQUERADE
Pozn.: zkoušel jsem různé varianty tunelů (10.0.0.1/24 <-> 10.0.0.254/24, 10.0.1.1/24 <-> 10.0.2.1/24), ale už jsem se do toho v podstatě zamotal a nechal jsem toho, budu zkoušet zase někdy příště...
P.
út 7. 5. 2019 v 21:51 odesílatel Jirka Bourek vpsfree-list@keroub.cz napsal:
Aha, tak jo. (Rejp: OpenVZ je divný a přiřazování různých IP na něco, co vypadá jako jedna síťovka, taky)
Pošlete sem výstupy ip addr show a ip route show z obou těch strojů - pokud budete skrývat adresy, tak ať je z nich poznat, které jsou privátní a které veřejné
Jinak to pravidlo s FORWARD NEW by AFAIK mělo být s dport 22, protože FORWARD ten paket vidí už upravený tím DNATem v PREROUTING.
Pravidla s PREROUTING vypadá taky dobře, ale aby to fungovalo takhle, tak je potřeba, aby buď
a) privátní IP adresa na tom druhém stroji byla na stejné (L2) síti jako na tom prvním stroji (tj. ping -t 1 ta.ip.adre.sa bude fungovat)
- nebo -
b) routery mezi těmi Vašimi stroji počítaly s tím, o co se pokoušíte (velká ptákovina, teoreticky by to šlo, prakticky na to zapomeňte a zkuste ten ping)
Pak je taky potřeba, aby ten druhý stroj, co má mít jenom privátní adresu, měl ten první stroj nastavený jako výchozí bránu, což podle toho výpisu route moc nevypadá.
Tak mě napadá, jak se na ten druhý stroj, který nemá veřejnou IP, připojujete teď? Z té webové konzole ve vpsadminu?
On 07. 05. 19 12:14, Pavel Hruška wrote:
Na podporu jsem psal jako první, tam mi poradili pohrát si s NATem a forwardem (což po diskuzi tady vidím, že asi nestačí) a pak mě odkázali
na
community :o).
Každopádně já jsem nic "ručně" nepřidával, mám k dispozici rozhraní (venet0), které má dvě IP adresy (a odtud venet0:x), privátní a public,
obě
adresy jsem samozřejmě dostal od provozovatele. Nevím, zda jsem udělal chybu, když jsem použitl venet0:x jako interface u iptables...
P.
út 7. 5. 2019 v 11:55 odesílatel Jirka Bourek vpsfree-list@keroub.cz napsal:
První věc, když vidím ta pravidla pro iptables: co je venet0:1? To je něco, co jste vytvořil pomocí ifconfig kvůli druhé IP adrese? Pokud jo, tak pro info, tohle je už víc než deset let zastaralé, kvůli přidání další IP adresy na rozhraní, které už nějakou má, není potřeba vytvářet žádné virtuální síťovky a stačí udělat tohle:
ip addr add y.y.y.y/z dev venet0
Druhá věc - pokud takhle přidáváte adresu k rozhraní venet0 (a platí to samé, i když to uděláte tím ifconfig), tak si to představte z pohledu provozovatele - ten vám nemůže (neměl by) dovolit, abyste si na síťovku nastavil jakoukoliv adresu, která se vám zlíbí. Co kdyby ji někdo používal? Rozumný poskytovatel zablokouje cokoliv, co pochází z Vašeho serveru, ale ne z IP, kterou Vám dal.
Na to, abyste mohl takhle propojit dvě VPS, potřebujete na té VPS, která má být přístupná z internetu, dvě síťová rozhraní. Je už v podstatě jedno, jestli to druhé bude nějaký tunel, VPN nebo co, ale pokud to chcete udělat rozumně, potřebujete dvě.
Takže bych doporučil napsat na podporu, čeho se snažíte docílit a jestli je možné to druhé rozhraní přidat. Uvidíte, co vám řeknou - podle toho můžete postupovat dál.
On 07. 05. 19 9:43, Pavel Hruška wrote:
Já jsem se (slušně) zeptal, protože nevím, jak situaci vyřešit. S
touhle
situací se totiž setkávám poprvé, takže si hned nedokážu představit,
proč
dvě síťová rozhraní nejsou ve stejné L2, proč to funguje tak a proč to nefunguje jinak. Nemusíš mi odpovídat jen proto, aby jsi mi řekl, že
tomu
nerozumím, to já totiž vím, jinak bych se neptal.
Pokud by se tedy našel někdo, kdo mi víc pomůže, budu rád.
Díky, P.
út 7. 5. 2019 v 9:23 odesílatel Stanislav Petr glux@glux.org napsal:
Jedno je tak mozna kolecko u trakare… Ale tak jak si to predstavujes
to
proste nejde IP protokol (IPv4 ani IPv6) nepodporuji indirect gateway
(to
umi napriklad nektere pokrocilejsi sitove protokoly, jako treba MPLS). Pokud spolu nejsou ty dve sitove rozhrani ve stejne L2 a nevidi na
sebe
primo, nemuze byt ten druhy pro prvni branou… Neboli vysvetli nam
jakym
genialnim zpusobem chces do site s prefixem /32 nacpat vic nez jednu
IPv4
adresu?
— Stanislav Petr
- 2019 v 8:31, Pavel Hruška mrpear@mrpear.net:
Privátní VLAN jsem nikde ve vpsadminu neviděl. To, že je veřejná
routovaná
jako /32 mi může být jedno, nebo ne? Prostě mi paket přijde na
veřejnou
VPSku, ta ho forwardne na privátní, nicméně pak se musí paket vrátit
zase
zpátky, což nevím, jestli jsem schopen na té druhé VPS udělat...
P.
po 6. 5. 2019 v 18:58 odesílatel Stanislav Petr glux@glux.org
napsal:
> Jedina moznost je udelat si mezi servery napr. ipip tunel a routovat
to
> prez nej. Verejny adresy jsou na VPS routovany jako samostatny /32
routy.
> Pripadne jestli jde nekde ve vpsadminu udelat privatni VLAN... > > Odesláno z iPhonu > > 6. 5. 2019 v 15:43, Pavel Hruška mrpear@mrpear.net: > > Ahojte, > > potřeboval bych poradit, resp. ujistit, že je to možné a nedělám > nějakou hloupost. Vzhledem k nedostatku public IPv4 chci mít druhou
VPSku
> pouze s privátní IP a chci si na ní směrovat určitý provoz (tcp
porty)
z
> venku z public IPv4, kterou má první VPSka. Na začátek si chci zřídit
SSH
> přístup, tedy například z veku x.x.x.x:222 -> y.y.y.y:22. Běžně NAT
dělám
> přes iptables. > > Tohle jsem zkoušel: > iptables -t nat -A PREROUTING -d x.x.x.x -p tcp -m tcp --match > multiport --dports 222 -j DNAT --to-destination y.y.y.y:22 > iptables -A FORWARD -i venet0:0 -o venet0:1 -p tcp -m tcp --match > multiport --dports 222 -m conntrack --ctstate NEW -j ACCEPT (tady
přesně
> nevím, jestli cílový port je 222 nebo 22, ale zkoušel jsem oboje) > > Plus toto: > iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j
ACCEPT
> > sysctl net.ipv4.ip_forward > (vrací net.ipv4.ip_forward = 1) > > Něco mi říká, že bych na té druhé VPSce měl mít bránu zpět na tu
první
> VPSku, ať se pakety můžou vracet, nicméně pokud dělám traceroute, tak
mi
> jde provoz přes nějakou pro mě neznámou bránu, ačkoliv route vidím
takový:
> > Kernel IP routing > table > Destination Gateway Genmask Flags Metric Ref
Use
> Iface > default 0.0.0.0 0.0.0.0 U 0 0
0
> venet0 > > traceroute to seznam.cz (77.75.74.172), 30 hops max, 60 byte > packets > 1 172.16.0.27 (172.16.0.27) 0.050 ms 0.017 ms 0.014 > ms > 2 vl128.cr3.r1-8.dc1.4d.prg.masterinter.net (81.31.40.97)
0.389 ms
> 0.629 ms 0.60 > ... > > Nevím, jestli dělám něco úplně špatně, nevím jak do toho zasahuje > OpenVZ, atd... Budu rád za každou radu, díky. > > > P. > > _______________________________________________ > Community-list mailing list > Community-list@lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list > > _______________________________________________ > Community-list mailing list > Community-list@lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list >
-- Ing. Pavel Hruška mrpear@mrpear.net
web, webdesign, web-aplikace: https://www.pearfect.cz http://www.pearfect.cz/ _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list