Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: David 03. 05. 2012, 09:27:25
-
Ahoj, snažím se pomocí OpenVPN propojit dva počítače za NATem.
PC1 ---- NAT1 ----- INTERNET ------ NAT2 ---- PC2
Na NAT2 je nastavený port forwarding na PC2. K NATu1 přítup nemám. PC1 posílá v pravidelnýh intervalech na veřejnou IP NATu2 na port 8000 UDP pakety, NAT2 je potom posílá na PC2 na témže portu. PC1 používá jako bránu do internetu právě NAT1.
Až dosud je to OK, s PC1 se spojím, veškerá komunikace ok (ping apod.) žádný problém. Problém nastane až když restartuju můj router (NAT2) po restartu už žádné pakety na port 8000 nepřichází! Routeru se po restartu vždy přidělí stejná IP adresa - ale nemám ji zaplacenou, ale několik let už dostávám tu samou. Pakety z PC1 jsou však stále odesílány - ověřeno pomocí tcpdump -i eth0 'port 8000'
Nenapadá vás někoho, kde může být chyba? Čekal bych že po restartu routeru budou pakety zase chodit ... ale vypadá to jako by se někde po cestě "ztratily"...
Díky za nápady
-
A co je třeba udělat, aby to zase začalo fungovat?
-
Změnit libovolně port - třeba na 8010 (tz. změnit forwardovaný port na NAT2 plus konfiguraci OpenVPN na PC1 a na PC2).
Teď mohu vyzkoušel pouze restartovat OpenVPN na PC1 - ale nevidím důvod, vypadá to že UDP pakety stále odchází na 8000 a nevidím důvod proč by to NAT1 najednou začal zahazovat... ale na port 8000 na NAT2 prostě nic nepřichází...
Jinak když to funguje tak to funguje třeba i několik dní bez problému, šlape to nádherně, vždy se ty pakety ale ztratí po restartu routeru - neboli NATu2 nebo ještě líp (adsl2+ modemu) a je potřeba provést výše uvedené, možná by ale stačil restart OpenVPN? Ale nevidím nějaký smysluplný důvod..
-
A nepomohlo by použít TCP místo UDP?
UDP by mělo být rychlejší, ale TCP spolehlivější - vzhledem k tomu, že s tou spolehlivostí je problém, možná by to stálo za zkoušku.
-
O tom jsem už přemýšlel, ale někdo zmiňoval že TCP over TCP může dělat psí kusy ohledně congestion controll apod.
-
Mimoto PC2 není permanentně zapnutý... PC1 je zapnuto permanentně, ale nemůže fungovat jako server, protože je právě za tím natem...
-
Takze problem nastane opravdu po restartu routeru NAT2? PC2 pri tom zustane bezet?
Tohle je potreba si vyjasnit a pak teprv resit dal.
Pokud ano, tak to muzeme zuzit na to, ze to s OpenVPN vubec nesouvisi a proste jenom router nepropousti po restartu pakety tam, kam by mel? To asi teda bude chtit se v konfiguraci toho routeru trochu pohrabat a zjistit, proc se chova tak divne (napr. nedochazi nahodou k tomu, ze konfiguraci pri restartu zapomene? Nebo neco takovyho...)
Taky jsem moc nepochopil tohle:
ale na port 8000 na NAT2 prostě nic nepřichází...
Jak to vis? Myslel jsem, ze NAT2 je, jak pises, adsl modem. Na nem jsi teda asi ten tcpdump nespoustel, ne?
Proste chtelo by to postupne proverit celou cestu a zjistit, kde se vlastne pakety ztraci:
1. prichazi na NAT2?
2. opousteji NAT2?
3. prichazeji na PC2?
-
No, ještě co dělá ten NAT2 (nebo je v síti za ním) - pokud by to bylo přiměřeně inteligentní zařízení, mohlo by dělat OpenVPN server samo, třeba nějaký RouterBoard (např. RB750 je v krabičce za nějaký 850Kč).
-
No, ještě co dělá ten NAT2 (nebo je v síti za ním) - pokud by to bylo přiměřeně inteligentní zařízení, mohlo by dělat OpenVPN server samo, třeba nějaký RouterBoard (např. RB750 je v krabičce za nějaký 850Kč).
Jestli je to ADSL modem, tak to tak jednoduchy nebude - viz podobobny dotaz tady na foru jinde.
-
Tak jsem zjistil že po restartu modemu - NAT2 stačí restartovat OpenVPN na PC1... a vše jede zase v pohodě, není potřeba měnit port. Nechápu proč? Vždyť PC1 se snaží posílat pakety na NAT2:8000 pomocí UDP ať se děje co se děje... (ověřeno pomocí tcpdump na PC1) jestli to dobře chápu. Zde je moje nastavení, možná je tam něco špatně?
PC1:
remote xxx.xxx.xxx.xxx
port 8000
dev tun
ifconfig 10.0.2.1 10.0.2.2
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
resolv-retry 5
secret david.key
PC2:
float
port 8000
dev tun
ifconfig 10.0.2.2 10.0.2.1
route 10.0.0.0 255.255.255.0
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
resolv-retry 5
secret david.key
-
Tak jsem zjistil že po restartu modemu - NAT2 stačí restartovat OpenVPN na PC1...
OpenVPN se obecně může chovat trochu "zvláštně", pokud dojde k přerušení spojení, restartuje se server apod. Většinou se dá pochopit proč, když člověk zapne debugování, pořádně projde logy, prověří, že je pro pakety správně otevřená cesta atd. Bývá to třeba jenom nějaké čekání na timeout apod.
Z toho, co píšeš, ale poradit neumím, protože to je (pro mě) dost zmatená kupa informací: že nechodí pakety na NAT2 a je to ověřené tcpdumpem, potom teda že stačí restartovat OpenVPN (čili pakety zjevně chodí, ne že ne...) atd. atp.
Budeš muset prostě postupovat systematicky:
1. prověřit, jak pakety prochází před a po restartu
2. zapnout debug logování
3. podívat se, jak logy vypadají před a po restartu (tj. tehdy, když to funguje a tehdy, když to nefunguje)
4. přečíst si pečlivě ty řádky logu, kde se úspěšně navazuje spojení, a ty, kde se spojení navazuje neúspěšně
Na základě zmatené diagnostiky se poradit nedá.
-
Večer budu mít k dispozici logy, tak uvidím.
-
Takže jsem zapnul logování OpenVPN zvlášť do souboru a taky jsem pustil tcpdump na portu 8000 - obojí na PC1. OpenVPN dle logu pořád opakuje stejnou sekvenci - snaží se inicializovat P2P spojení s IP NATu2, také výstup tcpdumpu tomu odpovídá, pakety se celou dobu odesílají na správnou IP.
Co bych měl dál zkusit? Teď se v pohodě připojím, ale jakmile restartuju ten modem, kterej funguje jako NAT2 tak po tom restartu už na něj nic na portu 8000 nepřichází, ačkoli podle logů z PC1 se OpenVPN pokouší navázat stále spojení a pakety se stále na port 8000 odesílají...
Aby to začalo zase fungovat je potřeba vypnout na PC1 OpenVPN na nějaký čas - třeba hodina a potom ho zase zapnout a najednou zase pakety na NAT2 přichází - logy na PC1 vypadají stejně jako předtím....
Co bych měl ještě prověřit? Z těch logů toho zase až tam moc nevyčtu... a z toho co vyčtu mi přijde nastavení v pohodě.
Jinak ještě připomínám že mám sice veřejnou adresu, nemám však garantováno že je pevná - ale za posledních let se nezměnila - v tom snad ale problém být nemůže, ne?
Díky za trpělivost
-
Tohle je obecne zpusobeno prechytralym natem, typicky openbsd ci ruzne hardening patche linuxu.
Resenim je jedno z:
1) donutit openvpn klienta at pouziva nahodne zdrojove porty (cimz se vytvori novy nat pro kazde spojeni)
2) nepouzivat obskurni systemy pro nat v pripadech kdy jejich tvurci jsou zastanci nazoru ze pro 1:1 nat *neni* rozumne zachovavat zdrojovy port (?!). bohuzel toto casto plati i pro ruzne "krabicky", overit v tcpdumpu.
3) pouzivat tcp. problemy s congestion nejsou zadne, pokud si v openvpn nastavite spravne ratelimity na obou stranach.
-
Můj modem je D-Link DSL-2641B / ADSL2+, ten funguje jako NAT2, podle mě nefunguje jako NAT 1:1 jestli to dobře chápu, jelikož více strojů používá jednu IP. Každopádně problém v NATu na modemu to nebude, ne? Když to funguje před restartem, jinak s tímto modemem jsem s port forwardingem z WAN do LAN nikdy problém neměl.
Řešním by bylo použím TCP, ale přijde mi že je to zbytečné zatěžování.
Myslíte si, že tohle chování způsobuje ten modem?
-
Po restartu ten modem zapomene jak konkretne "zprznil" zdrojovy port spojeni a od toho se vsechny dalsi problemy odviji - kde konkretne je nutne se podivat na tcpdump na obouch stranach za natem, a jeste nekde mezi tema krabickama (tradicne technik upstream ISP).
Reseni jak uz jsem psal - bud kopnout do openvpn at pouziva jiny algoritmus prirazeni zdrojoveho portu (parametry lport ci naopak nobind), ci jeste lepe se na stateless protokoly nespolehat protoze na rozdil skype a SIP to nefunguje zrovna 2x dobre pres NAT pokud neni garance zachovani zdrojovych portu.
BTW, ten overhead u tcp je casto *mensi* nez udp (zkus empiricky iperf na necem jako 2Mbit DSL), schvalne jestli prijdes na to proc :)
-
Moc nerozumím termínu zprznil - myslel jsem že když pošlu něco na xxx.xxx.xxx.xxx:8000 tak to na cílový port 8000 dorazí, a pravidlo port forwardingu zajistí to že modem předá paket do vnitřní sítě na konkrétní stroj. NAT po cestě změní akorát zdrojový port... co se tedy přesně stane při tom restartu?
-
Tak jsem použil TCP a funguje i po restartu modemu... Kamarád má také internet od O2, jiný typ modemu a jemu to po restartu funguje i na tom UDP. Mohu tedy říci, že to prasí modem?
-
Nikdo nic?
-
Nikdo nic?
Je to pravděpodobný, ale pořád jsi nedodal pořádnou diagnostiku, takže se to nedá říct stoprocentně.
-
Vazne zkus ten --lport a udp, a nebo holt tcp ale hlavne s poradnym qosem at tam nemas pingy 5s :)
-
Tak jsem na to po dlouhém hraní s wiresharkem a otáčením modemu přišel.. bylo potřeba přidat do nastavení openVPN na PC1 toto:
tun-mtu 1452
fragment 1000
mssfix