[vpsFree.cz: community-list] {Disarmed} Re: Forwarding z public IPv4 na privátní

Pavel Hruška mrpear at mrpear.net
Wed May 8 08:58:18 CEST 2019 

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 at 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 at 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 at 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
> >>>>
> >>>>
> >>>> 7. 5. 2019 v 8:31, Pavel Hruška <mrpear at 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 at 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 at 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 at lists.vpsfree.cz
> >>>>> http://lists.vpsfree.cz/listinfo/community-list
> >>>>>
> >>>>> _______________________________________________
> >>>>> Community-list mailing list
> >>>>> Community-list at lists.vpsfree.cz
> >>>>> http://lists.vpsfree.cz/listinfo/community-list
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Ing. Pavel Hruška
> >>>> mrpear at mrpear.net
> >>>>
> >>>> web, webdesign, web-aplikace:
> >>>> https://www.pearfect.cz <http://www.pearfect.cz/>
> >>>> _______________________________________________
> >>>> Community-list mailing list
> >>>> Community-list at lists.vpsfree.cz
> >>>> http://lists.vpsfree.cz/listinfo/community-list
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Community-list mailing list
> >>>> Community-list at lists.vpsfree.cz
> >>>> http://lists.vpsfree.cz/listinfo/community-list
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Community-list mailing list
> >>> Community-list at lists.vpsfree.cz
> >>> http://lists.vpsfree.cz/listinfo/community-list
> >>>
> >> _______________________________________________
> >> Community-list mailing list
> >> Community-list at lists.vpsfree.cz
> >> http://lists.vpsfree.cz/listinfo/community-list
> >>
> >
> >
> >
> > _______________________________________________
> > Community-list mailing list
> > Community-list at lists.vpsfree.cz
> > http://lists.vpsfree.cz/listinfo/community-list
> >
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>


-- 
Ing. Pavel Hruška
mrpear at mrpear.net

web, webdesign, web-aplikace:
https://www.pearfect.cz <http://www.pearfect.cz/>

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Bez
virů. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20190508/04905121/attachment-0001.html>

More information about the Community-list mailing list