<p dir="ltr">Verejna IP musi byt na oboch stranach internetovej komunikacie. Inak by to cez internet nepreslo. <br>
Prisim nezamienat so _statickou_ verejnou IP.<br>
NAT sa moze robit na ziadnej, jednej, alebo oboch stranach priamo na koncovom bode alebo u providera.</p>
<p dir="ltr">Aj ked je ciel na dynamickej IP, da sa pouzit dynamicke DNS <a href="http://ddns.com">ddns.com</a> alebo viacero dalsich pristupnych sluzieb dynamickeho DNS. Na cielovej strane sa nastavi aby si zariadenie zaregistrovalo svoju prave pridelenu IP k menu do dyndns servera. Namiesto cielovej IP sa potom chodi na FQDN co je uplne bezne.<br>
Na cielovom routri sa nastavi forwarding portu/portov. Ak je NAT na cieli u providera, da sa dohodnut port forwarding tam.<br>
V takom pripade je PLC pripojene takmer rovnako, ako keby bolo priamo na internete, ale len zvolenym portom,portami si vsetkymi bezpecnostnymi rizikami. Roboticke servery skusaju vsetky ip a vsetky porty ci sa im podari zistit co tam je a skusit to prelomit znamymi utokmi.<br>
Vhodnejsim riesenim by bolo u zakaznika urobit nejaky server (linux/.../win) v DNZ kludne virtualku, nan sa pripajat cez vpn, a az z neho nat povolenu komunikaciu cez FW na PLC.<br>
Bezne OS maju vyrazne lepsiu oodporu v platani dier radovo v dnoch po tom, ako sa objavia. <br>
Obavam sa ze PLC fw diery dlho nebude riesit.<br>
PLC nemusia hacknut, staci ze mu takto zblbnu program ( pretecenie pamate/zasobnikov kvoli interruptom a pod.)<br>
a budete riesit preco vas program zblbol<br>
ked po vypnuti a zapnuti tam ziadna chyba nie je a vsetko bezi ako ma...</p>
<p dir="ltr">Dodo</p>