Vecās spēlītes tīkla uz Windows 7

Viena no, manuprāt, visu laiku labākajām spēlēm ir Baldur's Gate 2. Pirmā daļa tikko izlaista no jauna, drīz gaidāma arī otrā (nosaukumā klāt nāk Enhanced Edition). Bet arī oriģināls strādā vēl joprojām bez problēmām (nu gandrīz, skatīt zemāk). Pie tam tai ir milzīgs laika gaitā izveidots modu klāsts, kas ļauj pārvērst spēli pavisam savādāku.

Viens no lielajiem BG plusiem ir iespēja spēlēt tīklā - pat mūsdienās to piedāvā gandrīz tikai hack-n-slash RPG, bet tādas spēles kā SW:KoTOR un Dragon Age nekā (par pēdējo vēl neilgi pirms izlaišanas bija cerība, ka būs, bet nekā). To arī veiksmīgi darījām pāris nedēļu garumā. Tiesa gan, katru vakaru vispirms vajadzēja izcīnīties, lai tīkls strādātu.

Pirmā lieta, kas palīdzēja vismaz 10 reizes, tiesa gan, nav ne jausmas, vai tā tomēr nebija sagadīšanās – tā kā uz viena datora spēle tika laista no ārējā diska, izskatījās, ka Windows (7 64bit) katru reizi nojauc ugunsmūra (iebūvētā) uzstādījumus. Palīdzēja izdzēst esošo atļauju un, palaižot spēli, atļaut no jauna. Bet, kā jau rakstīju, tā varēja būt arī sagadīšanās.

Otrā un, visdrīzāk, īstā problēma ir Windows 7, DirectPlay un UPnP kopējā nesaderība. Kad pameklē ar šādiem vārdiem internetā, tad atrodami diezgan daudzi līdzīgi gadījumi, kad šo lietu kombinācija izsauc problēmas. Zāles ir pavisam vienkāršas - uz rūtera ir jāatslēdz UPnP funkcionalitāte. Mēģināju izdzēst UPnP uzstādītos nosacījumus, bet tas nepalīdzēja. Arī tikko restartēts rūteris neko nedeva. Tā arī neesmu sapratis, kas pēkšņi vakar mainījās, jo pirms tam viss strādāja... Lai arī konceptuāli šis nav tas labākais risinājums, pēc vairāku stundu čakarēšanās arī tas der.

VPN tīkli, kam pārklājas subnet adreses #2

Iepriekš rakstīju par jautrībām, kas iestājas, ja VPN tīkla IP adreses pārklājas ar lokālā tīkla IP adresēm. Toreiz secinājums bija, ka Windows 7 atšķirībā no Windows XP ar to tiek tīri labi galā. Šodien atklāju, ka ir viens gadījums, kad arī Windows 7 padodas.

Problēma rodas gadījumā, ja caur VPN savienojumu cenšas pieslēgties serverim, kura IP adrese sakrīt ar lokālo IP adresi (to, ko iedalījis WiFi u.tml.). Šajā gadījumā arī Windows 7 cenšas pieslēgties pie lokālā datora un nevis pie servera. Teorētiski neko nevar pārmest, taču galvassāpes tas var sagādāt, jo pēkšņi bez nekāda acīmredzama iemesla kāds serveris nestrādā.

Viens no risinājumiem ir mēģināt dabūt jaunu IP adresi, bet, tā kā DHCP adreses parasti tiek piesaistītas MAC adresei uz vismaz nedēļu, vienīgais variants ir mainīt lokālo MAC adresi (ja vien nav pieeja rūterim). Taču vismaz manai WiFi kartei tādas opcijas nav. Ja ir pieeja rūterim, tad pareizāka rīcība ir nomainīt lokālā tīkla IP adreses uz kaut ko pavisam random, piemēram, kaut ko no 10.x.x.x apgabala. Ar šādām adresēm ir krietni mazāka iespēja uzrauties uz šo problēmu, salīdzinot ar 192.168.0.x, kas ir noklusētās adreses vairumam rūteru.

VPN tīkli, kam pārklājas subnet adreses

Tikko uzkāpu uz negaidīta grābekļa ar Windows XP VPN tīkliem.

Situācija sekojoša:

  • dators ir WiFi tīklā ar adresi 192.168.0.120, maska 255.255.255.0;
  • pieslēdzās VPN tīklam, kuram norādīts, “Use default gateway”;
  • VPN tīkla gateway ir 192.168.4.1, DNS servera adrese ir 192.168.0.100.

Šādā situācijā mēģinot pieslēgties DNS serverim no Windows 7, viss notiek korekti. Taču uz Windows XP tā gluži nav. Uz Windows XP kā pirmais tiek pārbaudīts vai serveris, pie kura pieslēdzas, ir datora oriģinālajā subnetā. Ja tā, tad tas seko standarta uzstādījumam un, ignorējot jebkādus gateway, mēģina slēgties pa taisno pie servera. Kas, protams, tam nesanāk.

Viens no iemesliem, kāpēc Windows XP mūsdienās labāk vairs neizmantot…

Datoru klonēšana pa tīklu

IT olimpiādes vajadzībām visus gadus esam izmantojuši vienu rīku, kas ļauj datorus klonēt, izmantojot tikai savstarpējo tīkla savienojumu. Rīks ir Udpcast.

Rīks ir tīri labs, tikai ar dažiem niķiem. Viens no galvenajiem ir nespēja atpazīt jaunākos dzelžus. Bet tas tiek ik pa laikam uzlabots.

Viens nopietns niķis, kas sagādāja zināmas problēmas, ir cietā diska draiveru izvēle. Tā korekti strādā tikai, ja jau ar pirmo piegājienu izvēlas pareizo draiveri. Ja izvēlas nepareizu, konstatē, ka disku neatrod, ņem back un izvēlas no jauna, nekas nestrādā. Ja izvēlas ne tā, tad labāk uzreiz pārstartēt datoru.

Noderīga informācija, ko iepriekšējos gados nezinājām un kas iepriekš traucēja pietiekami veikli klonēšanu pabeigt, bija kompresijas izvēle. 100mbps tīklā bez kompresijas dati tā arī tiek sūtīt ar ~95mbps. Ja izvēlas gzip kompresiju, tad dati tiek sūtīti ar ~15mbps, iegūstot 50% ekonomiju, tātad kopā ~30mbps. Ja izvēlas lzop kompresiju, tad tiek saglabāti ~50% ekonomija, bet dati tiek sūtīti ar ~85mbps, tātad kopā ~170mbps. Diemžēl to, ka gzip ir tik slikta izvēle, uzzinājām salīdzinoši vēlu.