Vlákno názorů k článku ADSL: další podpisy od Martin Winzig - No system NAT a Verejne IP adresy se...

No system NAT a Verejne IP adresy se prece nevylucuje, ve vnitrni siti budou neverejne ip adresy a na routeru mezi internetem a vnitrni siti bude realizovan nat preklad 1:1 kterej bude resenej dinamicky podle toho jak se uzivatele prihlasuji.( V podstate totez jsem programoval, a zatim to podle popisu vypada ze ma Telecom reseni ktere je velmi podobne) a dalsi vec je ze normalni NAT je problem kuli tomu ze se za nim velmi spatne hledaji hrisnici !!

PS asi by by bylo asi vhodnejsi zvolit PPPoE vyse zminenej postup je vhodnej pro WISP operatory kde uzivatel dostane pres NAT stejnou IP adresu v ktere koliv casti nasi republiky, ale pro ADSL uzivatele kteri necestuji to je silenej opruz se neustale logovat.

No, drobná nepříjemnost (pro některé aplikace dist velká) je, že sice z pohledu vnějšího Internetu IP adresa toho stroje veřejná je, ale ten stroj sám neví a těžko může zjistit, jaká. Takže pokdud některé aplikace posílají IP adresu jako součást protokolu, třeba ftp v aktivním režimu, tak budou mít smůlu. Stejně jako IPsec.

>> ale pro ADSL uzivatele kteri necestuji to je silenej opruz se neustale logovat

urcite sikovny programator vymysli soft, ktory bude mat ikonku v systemovej liste a bude zabezpecovat prihlasenie a udrzanie spojenia ...

podobnu haluz som pouzival vo Svedsku - tam bolo potrebne sa logovat do WiFi - sialene dlhe username/password (asi 10 krkolomnych znakov) ... ten softik mi odporucali hned technici ;-)

Ale o tom PIsu pro WISP providery je tot reseni vhodne ale proc to delat takhle i u ADSL ?

Takova malickost... kdyz dojdou verejne routovatelne adresy pri prihlaseni, tak co? Odmitne mi dashboard sluzbu, kterou jsem si zaplatil a kterou platim mesicnim pronajmem? Vzdyt to prece neni charakter jako u modemu - zavolam, odmitne, muzu drzet hubu, protoze je to free. Taky bych se rozciloval, kdybych mel komercni dial-up...

Ja jsem to resim tamk ze kdyz vytrarim uzivatele tak mu pridelim bud
1)pevou verejnou IP adresu,
2)plovouci verejnou IP adresu.
3)Pouziva preklad.

takze pokud je uzivatel pripojen na AC kterej mu nemuze namapovat jeho IP adresu tak se pouzije jedna z verejnych, a pokud nejsou volne verejne Ip adresy tak se pouzije nat preklad.

Ale Crha v online rozhovoru tvrdi:

Bezproblémový bude provoz většiny standardních protokolů - např. http, https, ftp (v pasivním i aktivním modu), DNS , ICQ, atd.

To se uvidí - může to být vyřešeno, že ten NAT bude umět měnit i obsah paketů, nejenom hlavičky. A pak je otázka, které protokoly bude podporovat. Zatím jsem se to nikde nedočetl.

To je samozrejme technicky a teoreticky mozne, uz se tesim, jak zase ICQ zmeni protokol, uz se tesim na tu masinu, co bude na aplikacni/relacni urovni proxovat vselijake exoticke protokoly...

BTW Ten IPsec neuvedl proc? Inu, protoze to skutecne nepujde... a ruzne proprietalni VPN (napr. CIPE) rovnez ne (znad vyjma SSH ci SSL tunelu). K cemu tedy takove orezavatko a navic cena, hmmm opravdovy sunt je mozno prodavat jen za opravdu suntovni cenu...'-)

CIPE pres NAT neni problem. Naopak, je to idealni VPN (jen ten port do Win neni moc dobry :( ).

Ciste teoreticky by klient poskytovatel mohl nabidnout sluzbu s verejnout a pevnou IP tak, ze by vyrobil ke klientovi tunel (treba std. IPIP, pripadne CIPE).

Jediny predpoklad je vhodne vybaveni u klienta a castecne muze byt problem s MTU < 1500 coz v nekterych vyjmecnych pripadech (ale opravdu pouze vyjmecnych :) ) muze delat problemy.

Jo, jenomže ta věta před tím to popírá - cituji komplet

Použité řešení v překladu adres zaručuje provoz všech aplikací, které nepoužívají vkládání IP adres do datové části rámce. Běžné problému různých aplikací s překladem adres se nebudou vyskytovat především díky použitému překladu 1:1. Bezproblémový bude provoz většiny standardních protokolů - např. http, https, ftp (v pasivním i aktivním modu), DNS , ICQ, atd.

Takže informační hodnota je nulová - pan Crha není technik a tudíž neví, že třeba zrovna v aktivním módu ftp se vkládá IP adresa do datové části rámce.

Ja jen vim, ze u nas ve firme mame na firewallu linuxovej masquarading a aktivni FTP mi normalne funguje...

Však už jsem to psal, na Linux existují moduly, které umějí měnit i datový obsah paketů, třeba ip_masq_ftp, ip_conntrack_ftp, ip_masq_icq atd. Jak to ale bude u ČTc ADSL nevím.

Pro vyreseni problemu s MTU je vhodne nastavit v IPinIP
nad interface Tunnel (Cisco) MTu vetsi.
Fragmentuje se IPinIP ale packety uvnitř zůstávají v původním stavu. Což je lepší varianta.

T

Použití FTP v aktivním modu může a nemusí být funkční. To záleží na dané verzi SW. Občas se vyskytnou problémy s určitým IOSem ale jindy to zase bez problémů funguje.
Předpokládám, že funkční to bude.

T

Vse co jste napsal znam, jenze kdyz vypnete AH-cko v tunnel modu, tak jste s bezpecnosti trochu jinde.. - to uz mohu pouzit treba CIPE, ci jiny nestandardni tunel... nebo treba L2TP+PPTP..:-)<p>PS: Ja IPsec bez AH zasadne nepouzivam a nevim o nikom, kdo by tak ('dobrovolne') cinil, neco jineho je, ze cesti ISP delaji VPNka casto pouze s DES-56... dobre tak zakaznikum, ze si to nepohlidaji nebo nenajmou konzultanta, ktery to zajisti/proveri...

S IPSecem pres NAT je to trosku jinak a samozrejme komplikovanejsi.

IPSec se sklada ze dvou protokolu AH a ESP
AH resi bezpecnost hlavicek packetu (bez TTL a dalsich co se dynamicky meni pruchodem pres router) a vysledek se prepocita MD5 nebo SHA algoritmem.
Destination peer provede stejný výpočet a porovná výsledek.
Stejný = packet je OK, špatný = packet drop.

ESP skutečná šifrovaná část dat pomocí DES nebo 3DES.
Tvoří ji v podstatě data.

V tomto okamžiku je výsledek, že přes NAT se IPSec nedostane. ale...

IPsec funguje ve dvou modech. Tunnel a transparent.
Tunnel vezme cely L3 packet a přidá mu nové hlavičky.
Transparent provede AH a ESP nad stejnými daty.

Co bude fungovat ?
Z hlediska bezpečnosti a průchodnosti přes NAT je varianta
použití TUNNEL modu (hlavicky jsou šifrovany 3DES, takže je to lepší než jen MD5) a MUSI BYT VYPNUT AH na celém packetu. To že se mění vnější hlavičky už ničemu neubližuje.
A IPSec funguje.

T

Ve skutecnosti je to tak, ze AH a ESP mode jsou kazdy urceny pro zajisteni trochu neceho jineho a obecne nejsou rozhodne zamenne jeden za druhy. AH zajistuje autenticitu hlavicek paketu - tedy zjednodusene to, ze paket opravdu byl odeslan tamodsud odkud je psano, ze byl odeslan a ze cilova adresa je take autenticka. Nezajistuje ale ani neporusenost obsahu dat a ani jeji utajeni.ESP mode zajistuje prave neporusenost celeho paketu (tedy hlavicek i dat) a zajistuje i jeho utajeni.

Ja znam realne pripady nasazeni, kdy je ('dobrovolne') pouzivan ESP mode bez soucasneho pouziti AH - ackoliv by samozrejme autentizace "vnejsich" hlavicek zapouzdrenych paketu byla v zasade mozna. V mnoha pripadech totiz takove nasazeni neprinasi zadne realne vylepseni bezpecnosti - cimz nevylucuji, ze v konkretnich pripadech to muze byt jinak - ostatne, v pripade bezpecnosti je vzdy nutne provest analyzu konkretniho problemu a reseni prizpusibit realnym loklanim podminkam, potrebam a situaci.