Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: nofu 17. 12. 2014, 18:57:47
-
Potřebuju poradit pls, páč moje znalosti jsou zjevně nedostatečné. Na wiki jsem našel tenhle návod (http://wiki.mikrotik.com/wiki/Manual:Interface/PPTP#Connecting_Remote_Client), podle kterého jsem VPN po pár hodinách pátrání, jak co funguje, nastavil (nastavil jsem vše v části 5.1 Connecting Remote Client). Na VPN se připojím, vnější IP mám pak stejnou jako je veřejná IP routeru.
Problém: Pokud jsem na VPN ve stejném rozsahu (192.168.88.0/24) jako je router a počítače ve vnitřní síti, pak nic krom routeru nepingnu. Pokud přenastavím router, aby mi na VPN dával IP z jiného rozsahu (192.168.89.0), pak můžu pingnout vše v rozsahu 192.168.88.0/24, do sdílených složek ale můžu pouze pokud znám IP adresu cílového compu, síť procházet standardně nejde, nejsou vidět okolní počítače. To je řešení pro mě, ale ne pro stardardního uživatele.
Otázkou tedy je, co přenastavit, abych byl na VPN v rozsahu 192.168.88.0/24 a mohl pingnout okolní compy?
Router mám nastaven přes šablonu Quick Set jako Home AP, krom toho vše v defaultu (žádné směrování portů, žádná přidaná pravidla ve firewallu).
V LAN portu 1 je připojen VDSL modem od O2 nastavený do módu Bridge, na routru nastaveno PPPoE připojení.
V LAN portu 2 je přes switch připojena vnitřní siť.
Moje nastavení VPN:
/ppp secret print detail
Flags: X - disabled
0 name="XXX" service=pptp caller-id="" password="XXXXXXXX"
profile=default-encryption local-address=10.0.0.1
remote-address=192.168.88.200 routes="" limit-bytes-in=0 limit-bytes-out=0
last-logged-out=dec/17/2014 17:04:56Pokud je zde remote-adress z jiného rozsahu (třeba 192.168.89.200), pak ping funguje.
/interface pptp-server server print
enabled: yes
max-mtu: 1450
max-mru: 1450
mrru: disabled
authentication: mschap2
keepalive-timeout: 30
default-profile: default-encryptionZde jsem oproti návodu použil profil s šifrováním, nefunguje to ani bez něj. K čemu je max-mtu a max-mru netušim, takhle je to v defaultu, zkoušel sem i 1460, beze změny.
/interface ethernet print
Flags: X - disabled, R - running, S - slave
# NAME MTU MAC-ADDRESS ARP MASTER-PORT SWITCH
0 R ether1-... 1500 00:30:4F:06:62:A0 enabled none switch1
1 RS ether2-... 1500 00:30:4F:06:62:A1 proxy-arp none switch1
2 S ether3-... 1500 00:30:4F:06:62:A2 enabled ether2-master-... switch1
3 S ether4-... 1500 00:30:4F:06:62:A3 enabled ether2-master-... switch1
4 S ether5-... 1500 00:30:4F:06:62:A4 enabled ether2-master-... switch1Zde je jediný rozdíl, a to že mám ether2 jako slave, netušim však, jak ho přenastavit jako master, zda je to vůbec možné, případně co vše pro tuto možnost musí být splněno. Může to být právě ten problém, proč to nefunguje?
Když se připojím na klientovi, tak dostanu:
IPv4 adresa: 192.168.88.200
Maska podsítě IPv4: 255.255.255.255 - zde čuju problém, ale nemám představu, jak ho řešit
Výchozí brána IPv4: (nic)
Server DNS IPv4: 192.168.88.1
Server WINS IPv4: (nic)
NetBIOS nad TPC /IP: Ano
Díky za jakýkoliv nápad.
/je klidné možné, že jsem nenastavil něco, co vám zkušeným příde jako samozřejmé, tož do mě
//pokud není moje otázka jasná, či jsem zapomněl uvést něco podstatného, ptejte pls
-
Problem cujes spravne. Ty totiz mas IP sice stejne, ale v jinem rozsahu, coz sam vidis na te masce. Pokud to zmenis na jiny rozsah, tak to pinguje, protoze router dela presne to co od nej ocekavas, routuje. Duvodem, proc nevidis zarizeni bez jejich IP je to, ze ty rozpoznavaci mechanismy funguji na principu broadcastu, kterej ale routerem standartne neprojdou. Resenim je vytvorit L2 vpn misto L3 tunelu ktery pouzivas.
Zkus treba tohle:
http://wiki.mikrotik.com/wiki/Manual:Interface/L2TP
-
1) PPTP se již 20 let nepočítá mezi VPN technologie.
2) Když dáš klientovi na "VPN" IP z LAN segmentu, tak musíš na LAN portu v routeru povolit režim proxy-arp. Předpokládám, že tam máš interface jménem bridge-local, tak na něm.
3) Stejně ti nebude fungovat prohlížení síťového okolí, protože Mikrotik nemá funkci broadcast pass thru. Takže v síťovém okolí nic nalezené neuvidíš. Pokud na síťovém okolí trváš, tak musíš použít OpenVPN v L2 režimu. Co jedině můžeš, tak jména počítačů si namlátit do toho routeru pod dns static a pak se dá na ně funkčně odkazovat pomocí jména, když VPN klient použije rotuer jako DNS server (což dle nastavneí aktuálně máš).
-
Jinak to, že ether2 vidíš jako slave je dáno tím, že je včleněn jako port do virtuálního switche jménem bridge-local, stejně jako wifi karta. Takž to je v pořádku. Z pohledu vnitřní logiky tak nastavuješ jako LAN vnitřní port na routeru ten bridge-local a ne etherX interfejsy (ether3 až ether5 jsou připojeny přes hardwarový switch na ether2, takže v softwarovém switchi bridge-local je jen ten ether2 a wifina).
Délka MTU a MRU ti říká, jak dlouhé pakety se mají tunelovat uvnitř toho VPN tunelu. 1460 je celkem OK s ohledme na to, že jsi na ADSL. Záleží, jaké MTU/MTU je vyjendáno na té PPPoE lince. Maximálně bude 1492. To MTU/MRU pro VPNko musí být minimálně o 20 menší, jinak to nebude s Windows klietem fungovat, takže 1450 nebo 1460 ceclkem OK hodnota pro případ, že někde by tne tvůj tunek byl ještě uvnitř nějakého jiného tunelu.
Pokud použijrš to proxy-arp a klient na VPN bude mít IP z 192.168.88.X, tak v tom ppp secrets místo 10.0.0.1 jako local-address dej 192.168.88.1 (IP routeru na LAN).
-
Aaaa, vloudila se chybka při kopírování ze staršího nastavení, v ppp secrets je samozřejmě 192.168.88.1 a ne 10.0.0.1
Thx to M.
smoofy: Na ping pomohlo povolit režim proxy-arp na bridge-local, tak jak psal M.. Já měl proxy-arp povolenej na ether2, což je mi teď, po vyčerpávající odpovědi od M., jasný, že nemohlo fungovat.
M.: díky za perfektní vysvětlení! Právě tady koumám OVPN, až na certifikáty je mi všechno jasný, tož se s tim zkusim zejtra poprat.
-
Udělej OVPN jako iface a při bridguj to ke stávajícím ifacům. Pak máš transparentní bridge na obě strany a nemusíš řešit ptákoviny.
Nejsnadnější řešení
-
Díky za odpověď.
Nemohl bys to pls trochu rozvést? Ideálně tak, aby to bylo pochopitelné pro normálního smrtelníka :-[
-
Vytvoříš OVPN server na jedné straně jen jeho mód nebude IP ale ETHERNET pak na druhé straně uděláš profil a spojíš se s touto stranou. Jak si psal výše jsou tam třeba certifikáty v momente kdy to budeš mít spojené uvidíš v interface OVPN jako interface. Potom vytvoříš bridge a do něj dáš interface (eth port ) který potřebuješ a k němu přidáš do bridge i ten ovpn interface. To uděláš na obou stranách a máš transparentní bridge.
-
To uděláš na obou stranách a máš transparentní bridge.
Zbytku asi rozumim, ikdyž absolutně nevim, jak to nastavit >> budou pokusy a omyly :D Ale tomuhle teda nerozumim vůbec, co je myšleno pod "na obou stranách"? Mi napadá akorát na klientské stanici, ale tam to pude těžko, nebo se mýlim?
btw. nejni na tohle někde nějakej sluště zpracovanej tutorial?
Já sem na wiki našel tohle (http://wiki.mikrotik.com/wiki/Manual:Interface/OVPN#Setup_Overview), tam mi neni jasný, jestli tohle musim dělat pro každýho klienta nebo ne:
/interface ovpn-client
add name=ovpn-client1 connect-to=2.2.2.2 user=client1 password=123 disabled=no
/ip route
add dst-address=10.5.8.20 gateway=ovpn-client1
add dst-address=192.168.55.0/24 gateway=ovpn-client1
/ip firewall nat add chain=srcnat action=masquerade out-interface=ovpn-client1
No a s cetifikátem si už vůbec nevim rady, našel jsemtenhle propracovanej návod (http://), jenže zakufruju hnedle u prvního příkazu:
certificate create-certificate-requestMi to vypíše "template:" místo aby se to zeptalo na název souboru jako v návodu. Když vytvořim templete, tak to nepomůže, se pak jen zeptá na heslo a konec. Navíc, dále v postupu je potřeba linux, nejsem si jistej, že to pude udělat na nějakym liveCD.
Není nějakej jednodušší postup, jak získat ty certifikáty?
-
Tak začneme znovu o co se přesně snažíš ? Potřebuješ se spojit VPN kou třeba do práce na veřejnou IP ? nebo potřebuješ v nějaké vnitřní síti schovat trafik ?
Pokud třeba verze VPN do práce tak první otázka co je v práci ? Rsp je tam veřejná IP která leží na mikrotiku ? případně popiš jiné možnosti .
Pokud je tam mikrotik a na něm leží veřejka tak nemáš ještě vyhráno pokud do toho "serveru" nemáš přístup .
(http://forum.root.cz/home/mart/ovpn-server.jpeg) tady je obrázek serveru .
Co se týká OVPN vše je popsáno zde . http://wiki.mikrotik.com/wiki/OpenVPN (http://wiki.mikrotik.com/wiki/OpenVPN)
Jinak koukám že dole pořád snažíš routovat. Tohle řešení co sem "popsal" je prakticky jen "Switch" mezi různýma místama. Čili pokud to takhle uděláš budeš mít dostupné vše co bude přidáno v na ten bridge .
-
A jelikož jsem lempl tak neumím vložit obrázek tak alespoň odkaz
http://hn-moon.happytechnik.cz/et/ovpn-server.jpeg (http://hn-moon.happytechnik.cz/et/ovpn-server.jpeg)
-
Je to přesně jak si popsal, snažim se připojit VPNkou do práce na veřejnou IP (tu má MikroTik) a rád bych měl přístupé.
Bohužel sem total marnej, celej den se v tom vrtám a nejsem schopnej to rozchodit ani podle toho manuálu na wiki. Bohužel je tam tolik proměných, že nemám šanci zjistit, co kde je špatně. Buď je problém s cetrifikátama, nevím jestli mám správné, případně zda je používám správně, no a největší problém mám s konfiguračním souborem klienta openVPN na windowsech.
Kdybys měl náladu a čas se na to juknout, pokusím se popsat, co a jak sem tropil:
1. Certifikáty jsem vygeneroval podle tohoto návodu (http://muj.pruvodce.info/110018-vytvoreni-certifikatu-openvpn-ve-windows.html). Mám tedy tyto soubory: dh1024.pem, ca.crt, server.crt, server.key, client.crt, client.key
2. Do routru sem nahrál server.crt a server.key a pak jsem je v tomto pořadí naimportoval. Certifikát má pak před sebou "KT".
3. Nastavil jsem router podle manuálu na wiki (http://wiki.mikrotik.com/wiki/Manual:Interface/OVPN#Setup_Overview).
4. V compu jsem nainstaloval OpenVPN GUI a snažím se vytvořit konfigurační file. Ať dělám co dělám, tak se to snad ani nezačne připojovat, píše to jen Curent State: Connecting a pak to vyhodí hlášku Connecting to Client failed. Co mi ale hlava nebere, jak to může fungovat bez uživ jména a hesla, co sem našel na netu, tak ho nemaji v žádnem tom konfiguračním souboru.
-
Musíš naimportovat i ca.crt do RBčka.
Konfigurace klienta pro Windows proti RBčku:
dev tap
proto tcp-client
remote 1.2.3.4 1194
tls-client
port 1194
ca ca.crt
cert client.crt
key client.key
script-security 2 system
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
mute-replay-warnings
verb 6
cipher AES-256-CBC
auth SHA1
pull
Patřičně si oprav IPčko 1.2.3.4. dále, pokud máš firewall na tom Mikrotiku, tak musíš mít povolen port 1194/TCP.
-
Certifikát jsem nakopíroval, certifikát server je v MikroTiku "KT", což se zdá správně, podle toho co se píše na netu.
Za konfigurák díky, konečně to něco dělá, ale nepřipojí se to. Nejdále jsem se dostal, když jsem změnil "dev tap" na "dev tun" - OVPN server mam totiž v módu IP. Samo sem ho zkoušel přepnout do módu Ethernet, taky se nepřipojim. Můžu sem případně hodit celej log. Log končí:
Fri Dec 19 09:29:43 2014 us=214195 TCPv4_CLIENT READ [22] from [AF_INET]XX.mo.je.IP:1194: P_ACK_V1 kid=0 [ 9 ]
Fri Dec 19 09:30:28 2014 us=942236 [XX.mo.je.IP] Inactivity timeout (--ping-restart), restarting
Fri Dec 19 09:30:28 2014 us=942736 TCP/UDP: Closing socket
Fri Dec 19 09:30:28 2014 us=943236 SIGUSR1[soft,ping-restart] received, process restarting
Fri Dec 19 09:30:28 2014 us=943236 MANAGEMENT: >STATE:1418977828,RECONNECTING,ping-restart,,
Fri Dec 19 09:30:28 2014 us=943236 Restart pause, 5 second(s)
Pravidlo do firewallu jsem přidal:
Chain: input
Protocol: 6(tcp)
Dst. Adress: XX.mo.je.IP
Dst.Port: 1194
Action: accept
Jest tak správně?
Je vůbec nějaké pravidlo potřeba, páč bez něj i s ním se to chová stejně. Podle návodu se nastavovalo:
/ip firewall nat add chain=srcnat action=masquerade out-interface=ovpn-client1
-
Pokud chceš používat OVPN v režimu IP (dev tun), tak jsi na tom úplně stejně, jako s tím PPTP. Je to L3 routovaný, síťové okolí nic neuvidí, to funguje jen v pokud je tunel L2, takže ethernet mód (dev tap).
PRavidlo vypadá OK, jd eo to, jde je umístěno, jeslti vůbec něco ve firewallu v input blokuješ.
Nejjednodušší zkouška je z klientskho počítače pustit
telnet XX.mo.je.IP 1194
zda se tne telnet spojí (nic nebude vidět), pokud ne a končí na timeout, tak něco cstu někde blokuje.
-
Tak telnet se asi spojil, po čase se ale odpojil.
Jelikož ale potřebuju OVPN v režimu ethernet, tak sem to celý shodil do defaultu a začínám znovu, tož prosím o pomoc, páč si s tim absolutně nevim rady.
Vnitřní sít je v defaultním rozsahu 192.168.88.0/24
Co jsem udělal:
1. naimportoval jsem certifikáty
2. vytvořil jsem poole "ovpn-pool" 192.168.89.2-192.168.89.10
3. vytvořil jsem PPP profile "ovpn" - nejsem si jistej, jak má být v tomto případě definovaná Local address, zda tam má bejt 192.168.89.1 nebo tam má bejt ovpn-pool jako je v Remote address? Budu tam posléze, až bude vytvořen, zadávat nějakej bridge?
4. v secrets jsem vytvořil uživatele s profilem ovpn
5. zapnul sem OVPN server, mode změnil na ethernet, default profile na ovpn, vybral certifikát a zaškrtl Requaire Client Certificate, ještě jsem zaškrtl "aes 256"
Dál ale netušim jak :-[ Snažím se postupovat podle tohoto příspěvku:Vytvoříš OVPN server na jedné straně jen jeho mód nebude IP ale ETHERNET pak na druhé straně uděláš profil a spojíš se s touto stranou. Jak si psal výše jsou tam třeba certifikáty v momente kdy to budeš mít spojené uvidíš v interface OVPN jako interface. Potom vytvoříš bridge a do něj dáš interface (eth port ) který potřebuješ a k němu přidáš do bridge i ten ovpn interface. To uděláš na obou stranách a máš transparentní bridge.
Jak mám udělat toto? ...pak na druhé straně uděláš profil a spojíš se s touto stranou...
Abych dosáhl tohoto:v momente kdy to budeš mít spojené uvidíš v interface OVPN jako interface
-
http://hn-moon.happytechnik.cz/et/OVPN-Mikrotik-mikrotik-easy.jpeg (http://hn-moon.happytechnik.cz/et/OVPN-Mikrotik-mikrotik-easy.jpeg)
http://hn-moon.happytechnik.cz/et/OVPN-Mikrotik-mikrotik-easy-bridge.jpeg (http://hn-moon.happytechnik.cz/et/OVPN-Mikrotik-mikrotik-easy-bridge.jpeg)
-
Screen viz nahoře v odkazu je to nahrubo / narychlo nastavené ale funkční řešení mikrotik vs mikrotik . Přiznám se že v PC klientu sem to nikdy nedělal tak se skus chytit s toho. Ten pool je jen rozsah ip kterou dostaneš po připojení stačí s PC staticky jedna. V tom jak si to udělal by měla být tedy local 192.168.89.1 a remote by měl být ten ovpn-pool co ti přidělí DHCP když je to takhle . Na té straně serveru udělej bridge do něj dej všechny porty které potřebuješ pravděpodobně to bude ta část LAN pokud to tam není musíš to vytvořit a ten OpenVPN interface přiřaď ostatním LAN portům .
-
Marte, jenže jde právě o to, že on nechce Mikrotik-Mikortik spojení na L2, ale chce mít na jedné straně Windows kompl.
Nicméně strana VPN serveru se dá souhlasit. Jinak nemusíš dělat binding OpenVPN serveru, stačí v profilu nastavit místo IP adres jméno bridge a po připojení klienta se automaticky přidá daný port do bridge:
/ppp profile add name=profil-ovpn bridge=bridge-lan use-encryption=yes
/ppp secret add name=clovek password=heslo profile=profil-ovpn service=ovpn
Jinak k tazateli, kolabuje ti to ještě dříve, než se to dostane k těmto jemnostem. Chtělo by to celý log. Odhaduji, že novější ROSy začínají být citlivé na to, co je v certifikátech ohledně použití, případně jaké podpisové funkce jsou použity, takže to kolabuje na tom, že si neověří certifikáty a jejich účel.
-
Těď na to koukám a myslím že by ten pool v té ethernet (tap) verzi kdy to nění routované neměl hrát žádnou roli. Rsp by tam být vůbec neměl . To by se prostě mělo rovnou spojit , počkej až se tu objeví tajemný "M" nerad by sem tě nasměroval špatně ale logicky ten pool dává pak tvému PC ip adresu která je pak za natem v té firemní síti .
Netrpím "samomluvou" jen jak není člověk přihlášený tak to nelze editovat .
-
2. vytvořil jsem poole "ovpn-pool" 192.168.89.2-192.168.89.10
3. vytvořil jsem PPP profile "ovpn" - nejsem si jistej, jak má být v tomto případě definovaná Local address, zda tam má bejt 192.168.89.1 nebo tam má bejt ovpn-pool jako je v Remote address? Budu tam posléze, až bude vytvořen, zadávat nějakej bridge?
4. v secrets jsem vytvořil uživatele s profilem ovpn
5. zapnul sem OVPN server, mode změnil na ethernet, default profile na ovpn, vybral certifikát a zaškrtl Requaire Client Certificate, ještě jsem zaškrtl "aes 256"
Ty kroky 2 a 3 jsou v příápadě ethernet režimu zbytečné. spojení je na L2, na klientovi se na WinTAP síťovce zapneš DHCP klient a kyž tunel jede, tak se na síťopvku přidělí IPčko pomocí DHCP serveru, který v ROSu běží na bridge-local.
Ano, v tom ovpn profilu místo IPček a poolu se zadá položka bridge=bridge-local.
Pozor! V některých verzích ROSu je chyba, když se používá Ethernet režim (nebo BCP pro PPTP/L2TP/SSTP), tak stjeně něco musí být zadáno jako local/remote addres, jinak to nefunguje ani s ítm bridge=bridge-local.
Ale je možné, že se ti to pobije už na těch certifikátech a k tomuto to vůbec nedojde, proto by to chtělo celý log. Npříklad, pokud používáš stále WindosXP, tak ta utilitka na generování certifikátů udělá certifikát, který XPčka nevezmou (podpis pomocí SHA256). Dále novější verze ROSu kontrolují účel použití certifikátu a musí být definováno použití jako netscape type=client. Některé verze generovátka certifikátů tam tento atribut nevloží a pak smolík, server nedovolí připojení (a naopak,klient může ověřovat, že certifikát předložený serverem má správné atributy definující použití na straně serveru, ale v té poslané konfiguraci toto nebylo zapnuto).
-
Díky za spoustu námětů! Jelikož se to dost lišilo od mé předešlé konfigurace, zese jsem projistotu shodil router do defaultu a opět napíšu, co jsem přesně nastavil. Vycházel jsem ze screenshotu od Marta a upravil jsem to podle dalších postů.
Vnitřní sít je stále v defaultním rozsahu 192.168.88.0/24, firewall také defaultu, žádné směrování portů.
1. naimportoval jsem certifikáty (ca.crt, server.crt+key)
2. přidal pravidlo ve firewallu a posunul ho nad defaultní pravidla (Chain: input, Protocol: 6(tcp), Dst. Adress: XX.mo.je.IP, Dst.Port: 1194, Action: accept), podle ověření přes telnet nejspíš funguje
3. v PPP/Interface/Profile jsem vytvořil profil "ovpn-profile", kde jsem nastavil jediné a to Bridge: bridge-local, Local a Remote Address vyplněné nejsou. Ještě jsem změni TCP MMS na yes (podle M.)
4. zapnul jsem OVPN server, přepnul Mode: ethernet, certifikát jsem dal cert_2 (tj server.crt+key, cert_1 je v mém případě ca.crt) a zaškrt jsem volbu AES 256 (vyskytuje se ve většině konfiguračních souborů pro openVPN klienta)
5. v PPP/Interface jsem přidal OVPN Server Binding, který jsem nazval "ovpn-ether" a vyplnij sem tam User: ten který jsem vytvořil v Secrets
Pocaď správně?
6. v obrázku: zde je vidět iface tvořený OVPN - ano, vidím ho tam, také je tam původní "bridge-local"
7. v obrázku: v bridge přidáš tento iface do bridge s ostatníma portama - tady vůbec nevím co s tím, pokus:
7.a v Bridge/Bridge jsem přidal Bridge, nazval jsem ho "ovpn-bridge", Co mám nastavit do ARP, pokud ho teda mám vůbec tvořit? Enabled nebo Proxy-arp?
7.b Bridge/Ports jsem přidal Bridge port, Interface: ether2 (tj port vnitřní sítě), Bridge: ovpn-bridge, zbytek jsem nechal, jak je defaultně. No a dostanu Error Couldn't add New Bridge Port - device alredy added as bridge port (6).
Takže asi musim vybrat něco jinčího ve volbě Interface, ale co? Bojim se cokoliv zkusit, páč mam taký neblahý tušení, že když tam nastavim nějakou hloupost, tak se na ten router na dálku nepřipojim, mám ho přes celou prahu.
Bo je bod 7 úplně blbě?
M.: Log z openVPN klienta za současného stavu pošlu v zápětí, jelikož se zdá, že došlo k určitému posunu.
Netrpím "samomluvou" jen jak není člověk přihlášený tak to nelze editovat .
To nejde ani jako přihlášený, nebo teda nevím jak, netřeba si z toho dělat hlavu. Naopak jsem rád, za jakýkoliv podnět, třeba mi něco nakopne a zadaří se.
-
Současný konfigurák:
proto tcp-client
remote XX.mo.je.IP 1194
dev tap
nobind
persist-key
tls-client
ca ca.crt
cert client.crt
key client.key
auth-user-pass auth.cfg
ping 10
verb 3
cipher AES-256-CBC
auth SHA1
pull
mute-replay-warnings
Log:
Fri Dec 19 22:26:58 2014 OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 1 2014
Fri Dec 19 22:26:58 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Enter Management Password:
Fri Dec 19 22:26:58 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Dec 19 22:26:58 2014 Need hold release from management interface, waiting...
Fri Dec 19 22:26:58 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Dec 19 22:26:59 2014 MANAGEMENT: CMD 'state on'
Fri Dec 19 22:26:59 2014 MANAGEMENT: CMD 'log all on'
Fri Dec 19 22:26:59 2014 MANAGEMENT: CMD 'hold off'
Fri Dec 19 22:26:59 2014 MANAGEMENT: CMD 'hold release'
Fri Dec 19 22:26:59 2014 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Fri Dec 19 22:26:59 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Dec 19 22:26:59 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Dec 19 22:26:59 2014 Attempting to establish TCP connection with [AF_INET]XX.mo.je.IP:1194 [nonblock]
Fri Dec 19 22:26:59 2014 MANAGEMENT: >STATE:1419024419,TCP_CONNECT,,,
Fri Dec 19 22:27:00 2014 TCP connection established with [AF_INET]XX.mo.je.IP:1194
Fri Dec 19 22:27:00 2014 TCPv4_CLIENT link local: [undef]
Fri Dec 19 22:27:00 2014 TCPv4_CLIENT link remote: [AF_INET]XX.mo.je.IP:1194
Fri Dec 19 22:27:00 2014 MANAGEMENT: >STATE:1419024420,WAIT,,,
Fri Dec 19 22:27:00 2014 MANAGEMENT: >STATE:1419024420,AUTH,,,
Fri Dec 19 22:27:00 2014 TLS: Initial packet from [AF_INET]XX.mo.je.IP:1194, sid=5ae32751 99e9af1f
Fri Dec 19 22:27:00 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Dec 19 22:27:00 2014 VERIFY OK: depth=1, C=Cs, ST=Cechy, L=Prague, O=Firma, OU=IT oddeleni, CN=XX.mo.je.IP, emailAddress=jmeno@Firma.cz
Fri Dec 19 22:27:00 2014 VERIFY OK: depth=0, C=Cs, ST=Cechy, O=Firma, OU=IT oddeleni, CN=XX.mo.je.IP, emailAddress=jmeno@Firma.cz
Fri Dec 19 22:27:01 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Dec 19 22:27:01 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec 19 22:27:01 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Dec 19 22:27:01 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec 19 22:27:01 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
Fri Dec 19 22:27:01 2014 [XX.mo.je.IP] Peer Connection Initiated with [AF_INET]XX.mo.je.IP:1194
Fri Dec 19 22:27:02 2014 MANAGEMENT: >STATE:1419024422,GET_CONFIG,,,
Fri Dec 19 22:27:04 2014 SENT CONTROL [XX.mo.je.IP]: 'PUSH_REQUEST' (status=1)
Fri Dec 19 22:27:09 2014 SENT CONTROL [XX.mo.je.IP]: 'PUSH_REQUEST' (status=1)
Fri Dec 19 22:27:14 2014 SENT CONTROL [XX.mo.je.IP]: 'PUSH_REQUEST' (status=1)
Fri Dec 19 22:27:14 2014 PUSH: Received control message: 'PUSH_REPLY,ping 20,ping-restart 60,route-gateway 0.0.0.0,ifconfig 0.0.0.0 255.255.255.0'
Fri Dec 19 22:27:14 2014 OPTIONS IMPORT: timers and/or timeouts modified
Fri Dec 19 22:27:14 2014 OPTIONS IMPORT: --ifconfig/up options modified
Fri Dec 19 22:27:14 2014 OPTIONS IMPORT: route-related options modified
Fri Dec 19 22:27:14 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Dec 19 22:27:14 2014 MANAGEMENT: >STATE:1419024434,ASSIGN_IP,,,
Fri Dec 19 22:27:14 2014 open_tun, tt->ipv6=0
Fri Dec 19 22:27:14 2014 TAP-WIN32 device [Připojení k místní síti 2] opened: \\.\Global\{E353E580-36C8-48D5-A381-D3264B33D8FA}.tap
Fri Dec 19 22:27:14 2014 TAP-Windows Driver Version 9.21
Fri Dec 19 22:27:14 2014 MANAGEMENT: Client disconnected
Fri Dec 19 22:27:14 2014 ERROR: There is a clash between the --ifconfig local address and the internal DHCP server address -- both are set to 0.0.0.0 -- please use the --ip-win32 dynamic option to choose a different free address from the --ifconfig subnet for the internal DHCP server
Fri Dec 19 22:27:14 2014 Exiting due to fatal error
-
Heleť v tom logu :
ri Dec 19 22:27:04 2014 SENT CONTROL [XX.mo.je.IP]: 'PUSH_REQUEST' (status=1)
To [XX.mo.je.IP] si přepisoval i v tom LOGU ? nebo to tam máš pořád nastavené ? tam by měla být veřejka (veřejná IP) toho serveru.
Jen se hloupatě ptám. Jestli si to tam nezapomněl .
-
Editoval jsem log, přecijen se nemusí moje veřená IP válet všude na netu. Stejně tak jsem zeditoval jméno firmy, email atd. u certifikátu.
-
Nu, to vypadá dle logu skoro dobře. Hm. Zkus přidat do konfigurace Mikrotiku to:
"2. vytvořil jsem poole "ovpn-pool" 192.168.89.2-192.168.89.10
3. vytvořil jsem PPP profile "ovpn" - nejsem si jistej, jak má být v tomto případě definovaná Local address, zda tam má bejt 192.168.89.1 nebo tam má bejt ovpn-pool jako je v Remote address? Budu tam posléze, až bude vytvořen, zadávat nějakej bridge?"
Jako local address dáš to 192.168.89.1 a bridge samozřejmě bridge-local.
Pak se zkus připojit, co to bude dělat.
Pokud by se to nerozjelo, tak do konfiguračního souboru klienta přidej volbu "ifconfig-nowarn".
-
Funguje - obrovský dík všem zúčastněným!
Nejel PING do vnitřní sítě, bylo potřeba změnit pool na 192.168.88.2-10, což je logické, také bylo třeba změnit v ovpn-profile Local Address na 192.168.88.1 (to je spíše poznámka pro mě, až to budu za rok řešit znovu / hlava děravá)
Mám tu ještě jeden dotaz, asi bude třeba přenastavit firewall, ale vůbec nemám páru co a jak. Dočetl jsem se, že pokud mám veřejnou IP a ve firewallu mám dropnutej input, tak že mi hned najdou boti a začnou mi spamovat brutal force útokama přes ssh/ftp atd. Což se mi samozřejmě děje, útoky jsou ze spousty různých IP adres. Jak se tomu bránit? Bo to prostě neřešit?
-
Jasný, 2 hoďky googlim a nic, ono se stačí zeptat a ono se řešení hnedka samo vynoří: wiki.mikrotik (http://wiki.mikrotik.com/wiki/Bruteforce_login_prevention)
Jen se mi nedaří přidat hned první pravidlo z terminálu, když ho tam zadávám, tak napíšu:
add chain=input protocol=tcp dst-port=21Před tím "21" je to rovnáse zahnědlý (add chain=input protocol=tcp dst-port=21). Se nějak změnily pravidla zápisu? Přes terminál ten příkaz prostě nezadám (zůstane zahnědlé, i když celé pravidlo dopíši).
/nastavil sem si to ve winboxu, ale jen mi to zajímá, čim to
-
Aaaa, sem trdlo, ty příkazy se museji zadávat do /ip firewall filter a já je zadáva do "rootu".
Je ještě něco, na co bych se měl u firewallu zaměřit?
-
Tak jsem pořídil mikrotika i domu a přídu si jak alenka v říši divů. Nejsem schopnej rozchodit PPTP tunel (http://wiki.mikrotik.com/wiki/Manual:Interface/PPTP#Connecting_Remote_Client). Přitom v kanclu to běhá jak z praku. Všechno mam nastavené stejně. Vyhodí to chybu 807 (viz přiloženej obrázek).
Rozdíly:
1) v kanclu je připojení přes VDSL, doma jsem na UPC - je možné, že to UPC blokuje?
2) v kanclu je v routru routerOS 6.23, doma 6.24 - podezřívám právě verzi 6.24, tady je changelog:
*) ntp - fixed vulnerabilities;
*) web proxy - fix problem when dscp was not set when ipv6 was enabled;
*) fixed problem where some of ethernet cards do not work on x86;
*) improved CCR ethernet driver (less dropped packets);
*) improved queue tree parent=global performance (especially on SMP systems and CCRs);
*) eoip/eoipv6/gre/gre6/ipip/ipipv6/6to4 tunnels have improved per core balancing on CCRs;
*) fixed tx for 6to4 tunnels with unspecified dst address;
*) fixed vrrp - could sometimes not work properly because of advertising bad set of ip addresses;
Může něco z toho ovlivnivt fci PPTP či L2TP tunelu?
Případně, je nějaká šance, jak downgradovat router na 6.23, abych vyloučil tuto možnost? Našel jsem, že to jde příkazem /system package downgrade, ale to bych někde musel stahnout "routeros-x86-6.23.1.npk", ale ten zaboha nemůžu nikde najít.
-
RB951G-2HnD urcite neni x86 arch, ale mipsbe. stahuj http://download2.mikrotik.com/routeros/6.23/routeros-mipsbe-6.23.npk
-
Dík za rychlou reakci, verzí routerOS to neni. Je to mojí hloupostí, stačilo na firewallu povolit port pro PPTP. Co ale nechápu, tak v kanclu jsem žádný povolení nedělal a tam to funguje. To je rozdíl jestli je router připojenej přes UPC (musel jsem otevřít port na routeru) nebo přes PPPoE (tady port otvírat nemusim)? Kdyby někdo věděl, budu rád za osvětu, páč mi to hlava nebere. Firewally na obou routrech jsou v defaultu.
-
Ještě tady řešim jednu lumpárnu okolo VPN. Když jsem na ni připojen a pustím si ve VMware W7, kde se připojuju na placenou PPTP službu od české firmy VPNhosting, tak sem mi ta VPN sice připojí, ale jakmile si něco řekne o data, tak se ihned odpojí.
Může to mít souvislost s Max MTU a Max MRU (na svém routeru jsem zkoušel 1300 - 1500, chová se to stále stejně)?
Může vůbec funguvat PPTP tunel uvnitř jiného?
Pomohlo by je poprosit, zda by oni zmenšili Max MTU a Max MRU?
Bo uvažuju úplně špatně a problém je jinde?
-
Dík za rychlou reakci, verzí routerOS to neni. Je to mojí hloupostí, stačilo na firewallu povolit port pro PPTP. Co ale nechápu, tak v kanclu jsem žádný povolení nedělal a tam to funguje. To je rozdíl jestli je router připojenej přes UPC (musel jsem otevřít port na routeru) nebo přes PPPoE (tady port otvírat nemusim)? Kdyby někdo věděl, budu rád za osvětu, páč mi to hlava nebere. Firewally na obou routrech jsou v defaultu.
Ano, je v tom zásadní rozdíl. Defaultní firewall blokuje příchozí spojení skrz ether1, který považuje za WAN port. Takže na tom UPC připojení jsou příchozí spojení blokována a musel se povolit port 1723/TCP (PPTP ještě potřebuje protokol GRE, ale pokud je povolen v /ip firewall helpers PPTP helper, tak se povolí ve firewallu automaticky pro každé nové spojení).
Kdežto na tom firemním s ADSL nepříchází data z Internetu na ether1, ale skrz nové pppoe rozhranní a firewall si jich vůbec nevšímá a router je zcela volně otevřen pro příchozí spojení. Takže je jen otázka času, než ho někdo zapojí do sítě DDoS útoků přes DNS (pokud je povoleno odpovídání na vzdálené DNS dotazy a ADSL je od někoho jiného, než O2, který to blokuje u sebe) nebo NTP (pokud je funkce NTP serveru povolena).
Ještě tady řešim jednu lumpárnu okolo VPN. Když jsem na ni připojen a pustím si ve VMware W7, kde se připojuju na placenou PPTP službu od české firmy VPNhosting, tak sem mi ta VPN sice připojí, ale jakmile si něco řekne o data, tak se ihned odpojí.
Může to mít souvislost s Max MTU a Max MRU (na svém routeru jsem zkoušel 1300 - 1500, chová se to stále stejně)?
Může vůbec funguvat PPTP tunel uvnitř jiného?
Pomohlo by je poprosit, zda by oni zmenšili Max MTU a Max MRU?
Bo uvažuju úplně špatně a problém je jinde?
Mikoritk nemá problém s provozováním PPTP uvnitř jiného PPTP. Na tom vnitřním je třeba mít patřične zkrácené MRU/MTU, aby to fungovalo. Hodnota 1300 je víc než dostatečná. Protokol se přizpůsobí té menší hodnotě z předložených si vzájemně mezi serverem/klientem. Je otázka, jak máš nastaven routing, zda se ti to nezacyklí (nově otevřené vnitřní PPTP nerozbije routing toho vnějšího). Jiný důvod může být, že ten hosting nedovoluje vnitřní další tunelování a shodí ti to (a nebo, pokud na tom spojení dělají NAT, tak nemají korektní podporu pro PPTP v tom svém NATu).
-
Ono je to obráceně, primárně jsem na VPN Mikrotiku, vnitřním je tedy ta placená služba. Zkusim jim cinknout, jestli by nezmenšili MTU/MRU.
-
Ono je to obráceně, primárně jsem na VPN Mikrotiku, vnitřním je tedy ta placená služba. Zkusim jim cinknout, jestli by nezmenšili MTU/MRU.
A čím vytáčíš to vnitřní VPN? Pokud Mikrotikem, tak si v definici VPN klienta na ten "VPNhosting" patřičně sniž MTU/MRU na 1300, vypni volbu MRRU a server by se měl přizpůsobit tvému návrhu (pokud předložíš kratší hodnoty než server). Pokud ho vytáčíš pomocí Windows, tak tam je nutno udělat zásah do registrů.
Dále je vhodné mít zapnutou v Mikrotiku volbu "/ip firewall service-port enable pptp".
-
Díky za odpověď a zároveň sorry, sem to blbě popsal, je to takhle: jsem v itálii a potřebuju mít na svém compu českou IP adresu, takže jsem stále připojen přes PPTP tunel na Mikrotik, co mám doma v čechách. V tom samém compu mam ve VMware virtuální systém, u toho potřebuju jinou českou IP, takže mám zakoupenou PPTP VPNku od VPNhosting.cz. VPNhosting provozuju vlastně uvnitř tunelu, kterým jsem připojen na Mikrotik. Dnes jsem telefonoval VPNhostingem, podle toho co jsem pochopil, tak maji defaultně nastaveno max MTU/MRU na 1500. Z toho co jsi zde psal, jsem pochopil, snad správně, že to za této konstelace nemůže fungovat, že MTU/MRU na VPN hostingu musí být minimálně o 20 menší než na mém Mikrotiku. Uvažuju správně?
Ještě mi napadla jedna věc, oni umožňují připojení i přes OpenVPN, mohlo by takhle fungovat? Obešel by se tím problém s max MTU/MRU?
-
Takže potřetí, u PPTP se použije MTU té strany, která ho nabídne menší. Takže tne hosting klidně může mít MTU 1500 (s tím to skoro nikomu fungovat nebude, pokud nemá jumbo frames z domu až k hostingu), takže když klient nabídne menší hodnotu, tak se použije tato. Takže musíš sáhnout na hodnotu v tom virtuálu v e VMware, pokud je tam Windows, z kterého to vytáčíš, tak musíš udělat změnu v registrech. Např viz:
https://social.technet.microsoft.com/Forums/windows/en-US/9ebbccac-2ee2-48d5-a6ce-20382104788b/how-do-i-change-the-pptp-mtu-size
Jiný problém je NAT v cestě, PPTP nefunguje úplně OK přes NAT, takže je možné, že to kolabuje na tom, že pokud máš ten VMware virtuál připojen přes NAT, tak to blbne. V Mikrotiku je na to ta zmíněná volba "/ip firewall service-port enable pptp", která aktivuje modul upravující PPTP skrz NAT, aby to šlo.
Takže ano, pokud zkusíš použít OpenVPN místo PPTP proiti tomu hostingu, tak ti to třeba pojede.
-
placenou PPTP službu od české firmy VPNhosting
To je nějaký nepovedený vtip? Za tohle si někdo nechá platit? :o ;D :D
-
M.: Díky, popral sem se s tím, uspěl jsem ale až s OpenVPN, tož alespoň něco. Jen mám trochu strach, aby když padne OVPN, tak aby se neprovařila moje pravá IP, nejni na to nějakej fígl, jak tomu u windows zabránit? S klasickou VPN stačilo nastavit ve vlastnostech internetu proxy na localhost.
Lol Phirae: pokud znáš nějaké stabilní a rychlé řešení zadarmo, sem s ním pls. Určitě bych ho využil.