Sign In
Create Account
Back to top
 |
Chirurgia endoscopică a hipofizei
"Standardul de aur" în chirurgia hipofizară îl reprezintă endoscopia transnazală transsfenoidală. Echipa NeuroHope este antrenată în unul din cele mai mari centre de chirurgie a hipofizei din Europa, Spitalul Foch din Paris, centrul în care a fost introdus pentru prima dată endoscopul în chirurgia transnazală a hipofizei, de către neurochirurgul francez Guiot. Pe lângă tumorile cu origine hipofizară, prin tehnicile endoscopice transnazale pot fi abordate numeroase alte patologii neurochirurgicale. www.neurohope.ro |
Mikrotik RouterOS - configuratii diverse, tricks, etc
3 votes
Last Updated: Feb 22 2024 12:48, Started by
Tyby
, Jul 11 2019 16:43
·
17
17
#415
Posted 18 January 2024 - 13:26
|
nu, ma refer la MTU pe interfata wireguard.
/interface wireguard add listen-port=20001 mtu=1420 name=wg__R1 private-key="WE1yo39DunVIe4TQOSX0Kp7nm/rkLtP/Cp781tzRJXc=" |
#416
Posted 19 January 2024 - 00:15
|
@ogo,
Multumesc pentru hint-ul cu MTU. As vrea sa am ocazia in viata reala sa dau macar o bere pentru hint-ul asta. Poate ne iese sa ne vedem cumva undeva. 
|
#417
Posted 19 January 2024 - 10:37
|
Pt putin.
De cele mai multe ori, daca totul merge la prima vedere dar unele site-uri nu, sunt 2 variante: - mtu - dns (in plus, la ipv6 mai poate apare pmtu/icmp blocat). Strict la subiect 1420 pt wireguard e corect (ipv6 conform docs si 1440 chiar pt ipv4) dar atata timp cat nu poti controla pmtu-ul decat pana la CPE, uneori da cu rest si mai trebuie sa lasi de la tine. Cea mai buna varianta e sa incerci cu ping do not fragment sa vezi mtu-ul acceptat pana in serverul pe care il accesezi. ceva de genu' : ping -M do -s 1472 1.1.1.1 -c 3(default cloudflare stie mtu 1500 - daca nu merge e de undeva de la ISP-ul tau). daca aduni 8 de la icmp ping si 20 de la ip header = 1500 MTU. Quote
The overhead of WireGuard breaks down as follows: - 20-byte IPv4 header or 40 byte IPv6 header - 8-byte UDP header - 4-byte type - 4-byte key index - 8-byte nonce - N-byte encrypted data - 16-byte authentication tag So, if you assume 1500 byte ethernet frames, the worst case (IPv6) winds up being 1500-(40+8+4+4+8+16), leaving N=1420 bytes. However, if you know ahead of time that you're going to be using IPv4 exclusively, then you could get away with N=1440 bytes. LE https://lists.zx2c4....ber/002201.html © Jason A. Donenfeld (e tipu' care a inventat wireguard-ul) Edited by ogo, 19 January 2024 - 10:38. |
#418
Posted 19 January 2024 - 10:46
|
Strict la subiect 1420 pt wireguard e corect dar atata timp cat nu poti controla pmtu-ul decat pana la CPE, uneori da cu rest si mai trebuie sa lasi de la tine. Cea mai buna varianta e sa incerci cu ping do not fragment sa vezi mtu-ul acceptat pana in serverul pe care il accesezi. Da, toata documentatia zice 1420. In cazul meu, presupun ca pe undeva pe traseu (dupa ce pachetul a iesit din ultimul meu router) unul dintre hop-uri nu este multumit cu 1420 si face nazuri. Am folosit nmap cu scriptul asta ca sa gasesc PMTU-ul corect si acuma browserul din Linux-1 nu mai scuipa erori aparent aleatorii. |
#419
Posted 19 January 2024 - 12:02
|
Pt putin. De cele mai multe ori, daca totul merge la prima vedere dar unele site-uri nu, sunt 2 variante: - mtu - dns (in plus, la ipv6 mai poate apare pmtu/icmp blocat). Strict la subiect 1420 pt wireguard e corect (ipv6 conform docs si 1440 chiar pt ipv4) dar atata timp cat nu poti controla pmtu-ul decat pana la CPE, uneori da cu rest si mai trebuie sa lasi de la tine. Cea mai buna varianta e sa incerci cu ping do not fragment sa vezi mtu-ul acceptat pana in serverul pe care il accesezi. ceva de genu' : ping -M do -s 1472 1.1.1.1 -c 3(default cloudflare stie mtu 1500 - daca nu merge e de undeva de la ISP-ul tau). daca aduni 8 de la icmp ping si 20 de la ip header = 1500 MTU. LE https://lists.zx2c4....ber/002201.html © Jason A. Donenfeld (e tipu' care a inventat wireguard-ul) Mai toate documentatiile de pe net nu tin cont de pppoe, care mai papa si el 8 din cate stiu. Adica ar trebui sa pleci de la 1492. Sper sa nu bat campii. Eu am avut o problema la serverul de openvpn de pe home mtik. Portul default e 1194 udp, deci "8-byte UDP header". Numai ca eu aveam portul blocat la fostul serv si am trecut pe 443 TCP. Si teapa, ca headerul de TCP e mai mare decat la UDP. A trebui sa scad si mai mult MTU-ul Edited by kretzu77, 19 January 2024 - 12:17. |
#420
Posted 19 January 2024 - 12:13
|
as as side note, pt pppoe exista RFC4638 care spune ca pt Next-generation broadband network:
Quote a BRAS acting as a PPPoE server MUST support PPPoE MRU negotiations larger than 1492 octets in order to limit the amount of fragmented packets in networks in unele locatii, RDS (ca de el e vb aici) e fully compliant cu 4638 dar din pacate nu peste tot. Edited by ogo, 19 January 2024 - 12:14. |
#421
Posted 20 January 2024 - 12:52
|
Nu e peste tot.
:a rcs, daca te conectezi pe IP, merge. Daca te conectezi pe ddns-ul lor .... nope. Cel putin asa era cand am configurat eu openvpn-ul acasa |
#422
Posted 06 February 2024 - 07:35
|
Au pus cei de la MikroTik au făcut WireGuard pentru toată lumea, iar ei spun că ar folosi server-ele lor pentru relay.
Am testat și funcționează. Doar dai click, scanezi QR și aia e. Merge și cu export file. Sunt curios dacă aș putea face tunneling între două router-e și să fac push route Pentru traficul de pe al doilea. |
#423
Posted 06 February 2024 - 11:30
|
wireguard nu are "expresia" de push route (asta e de la openvpn)
dar strict la obiect, raspunsul este DA: poti split-tunneling folosind allowed-ips (posibil sa iti trebuiasca si o regula de masquarade). daca poti explica mai clar ce doresti -de preferat folosind subnet-uri in exemplul tau- sigur exista o solutie.
Nu e peste tot. :a rcs, daca te conectezi pe IP, merge. Daca te conectezi pe ddns-ul lor .... nope. Cel putin asa era cand am configurat eu openvpn-ul acasa nu are nicio relevanta ddns-ul cu MTU-ul - el face doar sa rezolve un nume intr-un IP - si-atat. |
#424
Posted 06 February 2024 - 11:51
|
Merge și OpenVPN. Am văzut că e în pachetul de testare ceva cu ovpn.
Mă gândeam la o soluție prin care să pot „lipi” două LAN-uri. Am încercat și cu soluția lor, aceea cu tunel GRE (și/sau EoIP), dar aveam nevoie de un alt VPN datorită faptului că nu erau IP-uri statice. În trecut am folosit și OpenVPN, până dădea eroare TLS și umplea log-urile în ambele părți. WireGuard mi s-a părut greuț, așa că am tras pe o parte. Ideea e că am un sistem de camere ce stă în spatele unui CG-NAT (rețea mobilă), dar aș vrea să îl pot accea de pe serverul VPN. De exemplu, am două LAN-uri separate: 192.168.88.0/24 (ambele). Inițal făcusem o legătură LAN1 =192.168.100.0/32=LAN2. A mers o vreme prin L2TP/IPsec, dar după o actualizare nu a ma mers. LAN1 este server LAN2 este client. Edited by KyKyKyKy, 06 February 2024 - 11:51. |
|
#425
Posted 06 February 2024 - 12:40
|
Heh.
Iti recomand sa schimbi subnetul unui lan. Overlapping networks nu face bine si sigur apar erori: “confuzezi” getaway-ul… Si da, se poate ce vrei. Iar wireguard greut?? E floare la ureche pe langa openvpn/ipsec si chestii d-astea arhaice  ))
|
#426
Posted 06 February 2024 - 14:01
|
Daca vrei sa ai acelasi broadcast domain, poti face tunel Wireguard/IPSEC/OpenVPN intre cele doua locatii si "legi" cele doua LAN-uri cu tuneluri/interfete EoIP care au peer-ul accesibil prin tunelul Wireguard/IPSEC/OpenVPN (https://help.mikroti...urationExamples).
Daca ai servere DHCP in cele doua LAN-uri trebuie sa le reconfigurezi ca sa nu foloseasca acelasi range CIDR. eg.: Pool_A: 192.168.88.50-192.168.88.99 Pool_B: 192.168.88.100-192.168.88.149 Edited by cralin, 06 February 2024 - 14:04. |
#427
Posted 07 February 2024 - 23:08
|
Oare RDS blocheaza porturile pentru L2TP peste IPsec ? Am configurat acusi Mikrotik ul cu server L2TP cu IPsec + firewall rules corect configurate dar un device remote nu se poate conecta....
|
#428
Posted 08 February 2024 - 00:09
|
Nu blochează. Vezi ce zic logurile, cel mai probabil nu este totul setat complet în mikrotik
|
#429
Posted 08 February 2024 - 00:31
|
Nu blochează. Vezi ce zic logurile, cel mai probabil nu este totul setat complet în mikrotik Gata, merge, aveam IPsec policy dezactivat ! |
|
#430
Posted 13 February 2024 - 08:53
|
Am facut astazi update la un ax3 folosind optiunea: check-for-updates de la 7.13.3 la 7.13.4. Dupa reboot, pe 5GHz numai trec de 100Mbps. Intampina cineva aceasi problema?
[LE] Reboot, la router de cateva ori si un release renew pe masina au rezolvat-o. Edited by Ravy, 13 February 2024 - 10:09. |
#431
Posted 22 February 2024 - 12:48
|
Eu încă nu i-am făcut update.
Încă nu mă îndur să stric uptime-ul. Am făcut actualizările pe wAP AC în schimb. |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
-
- Change Theme
- English
- Mark Community Read
- Termene & conditii
- Confidentialitate
- Consimtamant
- Cookies
- Help
© 2001-2024 Softpedia. All rights reserved. Softpedia® and the Softpedia logo are registered trademarks of SoftNews Net SRL.
Ora implicita a Forumului Softpedia este ora standard a Romaniei (GMT+2). Mai multe informatii →
⚠ Postarile afisate pe Forumul Softpedia reprezinta o opinie subiectiva a membrilor care le-au publicat si nu a SoftNews Net SRL.