Rozdělení rozsahu

[Mario]

Ještě dotaz jak nastavit tu veřejnou k zákazníkovi. Na wan port mu dám veřejnou IP a jeho brána bude veřejná ip z toho rozsahu /25 kterou dám na LAN interface brány do internetu kde je připojený zákazník, to je jasné.Ale když mám zákazníky na různých interface? To tu ip adresu nastavím na všechny interface na té bráně do internetu?

Díky

Pokud si ten rozsah přidělil danému iface tak to takto nefunguje.
Musíš ji odejmout z iface. Potom jako gw můžeš použít jakéhokoliv op přiřazené gw. Jako např vIP na wanu.
Přece nemůžeš někomu dat jo z rozsahu na jiným iface pokud to není v bridgi nebo sw.
Pokud se pletu opravte mne.

Jinak k tématu je ze všem dělám na hlavní gw nat 1:1 na odroutovanou interku. Ti co to chtějí přímo na iface tak l2tp na gw kde ji jim priradim. Klient co navazuje l2tp vždy pouze MK a no problemo.

Rozsah chci právě přidělit na všchny ifaces, zákazníci co chtějí veřejky jsou různě na všech. Dát je všechny do bridge?

[rsaf]

takto to nejde a nedělá se to. Máš několik možností:
- NAT 1:1, řešit problémy s tím spojené, hairpinning...
- co zákazník dávat /30 - je to nejlepší způsob, bohužel to hrozně žere IP adresy
- co zákazník dávat /31 - ne všude se dá /31 rozumně zprovoznit, jinak je to ale fajn a žere to polovinu toho co předchozí varianta
- dát na každý subnet co teď máš nějaký přiměřený rozsah /28 nebo /29 a z něj dát zákazníkům adresy. Moc ale nezískáš (do /29 dáš 5 místo 2 u /30) a hlavně nevíš, kolik jich kde bude a pokud budeš potřebovat zákazníka přehodit mezi subnety, musíš mu měnit adresu
- dobré řešení je asi používat PPPoE zakončené ideálně na jedné centrální GW nebo na několika málo místech v síti. Potom je jen otázka nastavení jestli má zákazník veřejnou nebo neveřejnou adresu, spotřebuješ jednu IP na zákazníka a třeba pomocí OSPF můžeš i jednotlivé (/32) adresy směrovat na různé GW v síti.

My se zákazníkům v první řadě snažíme veřejnou adresu rozmluvit (ptáme se na co to mají, zda počítají s jistými riziky a snažíme se najít jiné řešení - často to jsou kamerové systémy a zabezpečovačky, které ale dnes často mají nějaký cloud), pokud na to trvají, dostávají prostě natovanou 1:1. /30 dáváme jen firemním zákazníkům se službou řádově od 1000Kč/měs (ty taky připojujeme jinak - do VLAN mimo náš firewall/shaper, shaping tam děláme až na CPE), při nezaplacené faktuře je neodpojuje automat...

[Cheprer]

bridge je blbost, tim si zadelas jenom na problemy. Ale samozrejme je to easy "porky" reseni.
Routovani je strasne zahazovani verek... nevim ale kdyz za ne platis blby.
Proto jsem zvolil NAT + tunel k tem narocnejsim. Ti narocnejsi maji vetsinou i zalozni konektivitu, takze kdyz jim vypadne nas konekt, pripoji se a pokud je nase GW dostupna, tak stale vyuzivaji svou vIP od nas.

[iTomB]

takto to nejde a nedělá se to. Máš několik možností:
- NAT 1:1, řešit problémy s tím spojené, hairpinning...
- co zákazník dávat /30 - je to nejlepší způsob, bohužel to hrozně žere IP adresy
- co zákazník dávat /31 - ne všude se dá /31 rozumně zprovoznit, jinak je to ale fajn a žere to polovinu toho co předchozí varianta
- dát na každý subnet co teď máš nějaký přiměřený rozsah /28 nebo /29 a z něj dát zákazníkům adresy. Moc ale nezískáš (do /29 dáš 5 místo 2 u /30) a hlavně nevíš, kolik jich kde bude a pokud budeš potřebovat zákazníka přehodit mezi subnety, musíš mu měnit adresu
- dobré řešení je asi používat PPPoE zakončené ideálně na jedné centrální GW nebo na několika málo místech v síti. Potom je jen otázka nastavení jestli má zákazník veřejnou nebo neveřejnou adresu, spotřebuješ jednu IP na zákazníka a třeba pomocí OSPF můžeš i jednotlivé (/32) adresy směrovat na různé GW v síti.

My se zákazníkům v první řadě snažíme veřejnou adresu rozmluvit (ptáme se na co to mají, zda počítají s jistými riziky a snažíme se najít jiné řešení - často to jsou kamerové systémy a zabezpečovačky, které ale dnes často mají nějaký cloud), pokud na to trvají, dostávají prostě natovanou 1:1. /30 dáváme jen firemním zákazníkům se službou řádově od 1000Kč/měs (ty taky připojujeme jinak - do VLAN mimo náš firewall/shaper, shaping tam děláme až na CPE), při nezaplacené faktuře je neodpojuje automat...

Co zakaznik datat /32 routovane ...

Na routovane siti, kde je klasicky klient na sektoru s rozsahem, tak nastavim, jako kdyby nemel verejku. Tu jednu konkretni verejnou naroutuju na jeho CPE, kde pak misto maskarady dam src-nat. Pripadne dle potreby dst-nat pri pouziti dane verejky. (funguje na mikrotiku ...)

Nejelegantnejsi nejcistsi zpusob pri setreni verejek. Nemusis tak jakkoliv zasahovat do site (aj je postavena jakkoliv).
IP nemusi byt na danem CPE ani definovana . Nefunguje pak ping (pokud neni nastaven na dst-nat ci neni nastavena DMZ).

[rsaf]

Jasně, tato varianta mě nenapadla byť něco podobného taky místy používám. Navíc je to takové dost nestandardní řešení - nemůžeš jen tak pustit klienta do toho routeru aby si např. portforwardy nastavoval sám, nemůžeš u něj použít nějaký běžný (třeba jeho vlastní) router...

[iTomB]

Jasně, tato varianta mě nenapadla byť něco podobného taky místy používám. Navíc je to takové dost nestandardní řešení - nemůžeš jen tak pustit klienta do toho routeru aby si např. portforwardy nastavoval sám, nemůžeš u něj použít nějaký běžný (třeba jeho vlastní) router...

No a bezny router umi tunely? taky moc ne ... Nehlede na to, ze 99% klientu, co chteji verejku si to stejne neumi nastavit a zabezpecit ... Takze to nastavujeme my a hotovo. Firemni zakaznik to ma samozrejme jinak.

[miso7711]

Klientom chcem z CCR pomocou PPPoe pridelovat verejné/neverejné IPv4/IPv6 ip adresy

[rsaf]

Jasně, tato varianta mě nenapadla byť něco podobného taky místy používám. Navíc je to takové dost nestandardní řešení - nemůžeš jen tak pustit klienta do toho routeru aby si např. portforwardy nastavoval sám, nemůžeš u něj použít nějaký běžný (třeba jeho vlastní) router...

No a bezny router umi tunely? taky moc ne ... Nehlede na to, ze 99% klientu, co chteji verejku si to stejne neumi nastavit a zabezpecit ... Takze to nastavujeme my a hotovo. Firemni zakaznik to ma samozrejme jinak.

Podle mě je PPPoE celkem běžná funkce (když se dávají za DSL modem v bridge...)

[Pelirob]

Já vím že to je milionkrát omleté téma, ale chápu dobře, že pokud hlavní router dělá src/dst nat pro zákazníky s veřejkou, maškarádu pro ty ostatní, tak uděláš tunel na WAN port a tunelem posíláš vybrané IP adresy z rozsahu 85.85.85.0/24?
To sice funguje s PPtP tunelem, ale je otázkou nakolik v dnešní době je bezpečné PPtP ještě používat.

router.jpg (40.69 KiB) Zobrazeno 3455 x

bridge je blbost, tim si zadelas jenom na problemy. Ale samozrejme je to easy "porky" reseni.
Routovani je strasne zahazovani verek... nevim ale kdyz za ne platis blby.
Proto jsem zvolil NAT + tunel k tem narocnejsim. Ti narocnejsi maji vetsinou i zalozni konektivitu, takze kdyz jim vypadne nas konekt, pripoji se a pokud je nase GW dostupna, tak stale vyuzivaji svou vIP od nas.

[Myghael]

PPTP tunel funguje úplně normálně - v síti, která je alespoň trošičku důvěryhodná s tím není problém (například tunel mezi několika lokalitami v síti jednoho ISP), samozřejmě pokud chceš posílat důvěrná data přes celý svět, L2TP/IPsec, OpenVPN nebo něco podobného už dnes odvedou bezpečnější službu.

[Cheprer]

Já vím že to je milionkrát omleté téma, ale chápu dobře, že pokud hlavní router dělá src/dst nat pro zákazníky s veřejkou, maškarádu pro ty ostatní, tak uděláš tunel na WAN port a tunelem posíláš vybrané IP adresy z rozsahu 85.85.85.0/24?
To sice funguje s PPtP tunelem, ale je otázkou nakolik v dnešní době je bezpečné PPtP ještě používat.


router.jpg

bridge je blbost, tim si zadelas jenom na problemy. Ale samozrejme je to easy "porky" reseni.
Routovani je strasne zahazovani verek... nevim ale kdyz za ne platis blby.
Proto jsem zvolil NAT + tunel k tem narocnejsim. Ti narocnejsi maji vetsinou i zalozni konektivitu, takze kdyz jim vypadne nas konekt, pripoji se a pokud je nase GW dostupna, tak stale vyuzivaji svou vIP od nas.

Ano.
Bezpečně to ve vlastní sítí považují dosti.
Z venku běžně l2tp+ipsec.
I to pptp pokud je to prez backup linku třeba na hodinu dvě do roka tak to považují za malé riziko.
Samozřejmě kdo chce bezpečnost použije se l2tp s ipsec ale musí mít na to hw aby to zvládl a tudíž si to i zaplatit.
Hromada firem si od nás pořizuje verejku jenom kvůli propojeni vlastních poboček zkrze tunely, a kolikrát mu přijde dosti zbytečně aby se prez l2tp+ipsec ještě posílal eoip nebo jiný tunel na jejich gw ale hold to tak je.

Po vyzkoušení všech možných kombinací mi toto přijde jako jednoduchý způsob jak nemrhat vIP a mít v tom systém a mít to jednoduche. Jednoduší by už jenom bylo kdybych ani interním klientům nedělal nat ale přímo zase prez tunel jim to posílal a tunel vytacel zase z klientského mk/ubnt....Nevím co je méně hw náročné, ale představa ze na gw bude dalších desítky tunelu tak by mi to přišlo svým způsobem méně přehledné, možná více. Je to řešení nad kterým tak téže premyslim, že bych to tak to zjednodusil. Méně fw ale zase více tunelu.
Nevím jak ubnt ale MK jako hap apod... Moc vysoké rychlosti prez tunel nezvládnou zkrze cpu.
Má někdo nějaké lepší poznatky?

[Pelirob]

... Bezpečně to ve vlastní sítí považují dosti.
Aha tak že paranoici si nastaví fw. pravidla pro povolení PPtP tunelu tak, že budou platit jen pro příchozí provoz z vlastní sítě, ostatní ho povolí i z WANu, aby v případě nutnosti fungovaly backup linky. Takhle to bylo myšleno?
A hodně zajímavá myšlenka je ta, nad kterou jsem doteď neuvažoval : použít PPtP tunel jako řešení dostupnosti veřejné IP zákazníka při výpadu trasy někde mezi iGW a koncovým bodem zákazníka (teda pokud má nějakou backup linku). Může mít třeba menší rychlost, ale pojede na "svých" IP adresách.

Když je mikrotik jako koncový bod u zákazníka, je to easy. Ale dá se přes PPtP tunel řešit situace, když zákazník nechce jako firewall mého mikrotika, ale chce použít nějaký svůj hardwarový box? Tj. veřejku(-ky) z PPtP tunelu dostat přímo až do zákazníkova zařízení?

Já vím že to je milionkrát omleté téma, ale chápu dobře, že pokud hlavní router dělá src/dst nat pro zákazníky s veřejkou, maškarádu pro ty ostatní, tak uděláš tunel na WAN port a tunelem posíláš vybrané IP adresy z rozsahu 85.85.85.0/24?
To sice funguje s PPtP tunelem, ale je otázkou nakolik v dnešní době je bezpečné PPtP ještě používat.

Ano.
Bezpečně to ve vlastní sítí považují dosti.
Z venku běžně l2tp+ipsec.
I to pptp pokud je to prez backup linku třeba na hodinu dvě do roka tak to považují za malé riziko.
Samozřejmě kdo chce bezpečnost použije se l2tp s ipsec ale musí mít na to hw aby to zvládl a tudíž si to i zaplatit.
Hromada firem si od nás pořizuje verejku jenom kvůli propojeni vlastních poboček zkrze tunely, a kolikrát mu přijde dosti zbytečně aby se prez l2tp+ipsec ještě posílal eoip nebo jiný tunel na jejich gw ale hold to tak je.....

[Cheprer]

Hele těch zákazníků co nechtěli MK je dosti malo. Ale jsou. Taky na mě ajtaci vytáhly ze šuplíku super vigora apod...
Pokud si to umí nastavit ať si to nastavi, pokud neumí tak to nastaví specialistka za cenu kterou my rekneme. A vždy se domluvíme že řešení dodáme my, jelikož když firemnímu ajtakovi řeknu co si má nastavit tak většinou skloní hrb a konají podle instrukcí.
A těch zákazníků co nutně potřebují svoji veřejnou i v době výpadku není zas tak mnoho. Pár jich má vlastní poštovní servery atp... Ale těch je fakt pár.

[Pelirob]

No ale někde tam bude problém, akorát mě nedochází kde.
Když se PPtP tunelem dá dostat veřejka k zákazníkovi vcelku velmi jednoduše, proč tady každou chvíli někdo řeší, jak po síti routovat rozsah /30 kvůli tomu, že potřebuje veřejku u zákazníka.

Hele těch zákazníků co nechtěli MK je dosti malo. Ale jsou. Taky na mě ajtaci vytáhly ze šuplíku super vigora apod...
Pokud si to umí nastavit ať si to nastavi, pokud neumí tak to nastaví specialistka za cenu kterou my rekneme. A vždy se domluvíme že řešení dodáme my, jelikož když firemnímu ajtakovi řeknu co si má nastavit tak většinou skloní hrb a konají podle instrukcí.
A těch zákazníků co nutně potřebují svoji veřejnou i v době výpadku není zas tak mnoho. Pár jich má vlastní poštovní servery atp... Ale těch je fakt pár.