Cerams, lasi.lv un citas iesaistītās personas, lai kas tās arī nebūtu, piedos man šo necienīgo iesaistīšanos izsekošanas darbā, kas brīžiem raksturīgs Latvijas blogosfērai. Saintriģēja mani šis projekts.

Fakti

Uzdurties lasi.lv sanāca gluži nejauši no saites Twitterī.

Projekts izskatās izstrādāts no nulles un diezgan labi paveikts. Varētu kļūt par nīkuļojošā digg.lv aizvietotāju.

Interesantākais un Latvijā neierastākais ir tas, ka lasi.lv hostējas uz Google App Engine, kas ir pirmais plašām masām pieejamais distributīvais hostings, izmantojot Google Apps for Your Domain produktu. Tā kā uz šīs platformas izstrādē lietojams tikai Python, nav brīnums, ka šī aplikācija tiek darbināta ar Django ietvaru (piekam praktiski svaigāko versiju). Pagaidām, kamēr nav izslēgts atkļūdošanas režīms publiskajai lapai, to itin labi var konstatēt šādā te kļūdainā saitē - http://lasi.lv/asdf/.

Patlaban Latvijā tas pilnīgi noteikti ir nozīmīgākais plašai publikai lietojams projekts, kas balstīts uz šīm jaunajām tehnoloģijām.

Pieņēmumi un spekulācijas

Man zināma ir tikai vēl viena cita Latvijas lapa, kas izmanto Google App Engine platformu — proti Aivja Ābeles blogs. Iespējams, ka viņam arī ir kāda saistība ar šo projektu, bet tikpat labi arī nav.

Domēns reģistrēts uz cilvēku, kuram tīri laba muzikālā gaume.

Visādā ziņā interesanti un prieks, ka šāda kalibra projekts nenāk no tā saucamajiem usual suspects.

Lai gan var jau būt, ka Mika jautājums par lasi.lv bija vien mārketinga triks un patiesībā lasi.lv ir kārtējais Alberta projekts.

Papildinājums, 27.08.2008 22.42
Izskatās, ka atkļūdošanas režīms lasi.lv izslēgts. Apstiprinājums, ka lasi.lv hostē Google.

E-pastā ieskrēja uzaicinājums apmeklēt RedHat konferenci 4. septembrī viesnīcā “Gūtenbergs”.

Kā informācijas lapā atzīmēts — tā ir pirmā RedHat konference Latvijā. Šķiet agrāk ir bijuši dažādi ar Linux saistīti pasākumi, bet nav bijis pasākums, kur vairāk par pusdienu stāsta par kādu konkrētu distributīvu.

Pats nedomāju piedalīties, bet, ja nu kādam interesē, programma sekojoša:

09.30 – 10.00 Reģistrācija, kafija
10.00 – 10.15 Semināra atklāšana
10.30 – 11.15 Red Hat biznesa modelis un stratēģija *
11.15 – 12.15 Red Hat Linux produkti, licenzēšana
12.15 – 12.30 Kafijas pauze
12.30 – 13.30 JBoss produkti*
13.30 – 13.45 Red Hat apmācība*
13.45 – 14.00 Red Hat Latvijā
14.00 Jautājumi un atbildes
14.15 Pusdienas, dzērieni

* priekšlasījumi būs angļu valodā

Interesanti, ka e-pastu sūtīja GNT Latvija, nevis LATA, LAKA vai vēl kāds cits.

Pasākuma ieviešana notika uz Windows vidē. Klienta pieslēgumam vajadzētu strādāt arī no Linux un citām operētājsistēmām, taču tas nav pārbaudīts.

1. VPN konfigurēšana uz Windows Server 2003

Jāpievērš uzmanība:

• nepieciešamas divas tīkla kartes
• Routing And Remote Access vednis
• lietotājam iespējots Remote Access Permission Dial-in tabā

Idejiski viss ir ļoti vienkārši: tikai jāieslēdz Routing And Remote Access serviss un, izmantojot vedni, jāieķeksē VPN atbalsts. Jāņem gan vērā, ka atšķirībā no Linux serveriem VPN var nokonfigurēt tikai tad, ja ir vismaz divi fiziski tīkla interfeisi. Virtuālu tīkla kartes draiveri neizdevās atrast, tāpēc nācās serveros ielikt faktiski nevajadzīgu papildu tīkla karti.

IPSEC savienojumu veidojot, biju slinks un nemēģināju to nokonfigurēt, izmantojot drošības sertifikātus, tā vietā uzstādīju koplietošanas atslēgu (pre-shared key) Routing And Remote Access servisa uzstādījumos Security tabā, kas jāizmanto, pieslēdzoties no klienta.

2. Izmantoto tīkla protokolu un portu atvēršana

Nepieciešami:

• UDP 500 (pamata) un UDP 4500 (ja tiek izmantots NAT) porti
• IP protokols 50

Ar šo pirmā daļa ir pabeigta un brīnumi tikai sākas. Nākošais grūtais uzdevums ir iestāstīt tīkla administratoriem, kādi caurumi jāattaisa vaļā ugunsmūrī, lai VPN varētu arī pieslēgties no ārpuses un pēc tam diagnosticēt problēmas, kad tomēr nestrādā kā gaidīts.

IPSEC savienojumam nepieciešams atvērt UDP portu 500 un IP protokolu 50, 99% gadījumu klienti slēdzas klāt no iekšējām tīkla adresēm, kas atrodas aiz NAT rūtera, tāpēc nepieciešams atvērt arī UDP 4500 portu.

3. Atvērto portu pārbaude

Lai pārbaudītu, vai tiešām porti atvērti, izmantoju UDP klausīšanās serveri un klientu, jo citādi UDP portu vaļā esamību pārbaudīt ir diezgan grūti. Lai varētu testa UDP klausīšanos palaist uz 500 un 4500 portiem, vispirms jāapstādina tos izmantojošais Local Security Authority serviss. Konkrētajā gadījumā lietoju PCATTCP, bet vēl drošvien var arī izmantot kādu Netcat rīka Windows versiju. Šoreiz administratori bija pamanījušies aizmirst atvērt 4500 portu un gluži dabiski pieslēgties no datoriem aiz NAT tīkla neizdevās.

Cits veids, kā diagnosticēt iespējamās problēmas, ir izmantot Wireshark tīkla pakešu analizatoru. Viegli pamanīt atšķirību starp strādājošu un nestrādājošu VPN pieslēgumu un redzēt, kurā vietā kaut kas nenotiek kā vajadzētu.

4. Ja serveris pats ir aiz NAT un klients ir Windows XP

Otrā uzstādīšanas reizē aiz NAT atradās pats Windows serveris, tāpēc lai no Windows klientiem varētu pieslēgtiem bija nepieciešama neliela konfigurācijas izmaiņa reģistrā.

Windows XP SP2+ gadījumā nepieciešams reģistra atslēgā HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec pievienot DWORD ierakstu AssumeUDPEncapsulationContextOnSendRule ar vērtību 2.

5. Papildus

Noderīga informācija par LT2P/IPSEC protokolu atrodama tā Linux implementācijas aprakstošā mājaslapā.

Gadījās man arī nepatīkams pārsteigums — jaunajam remote desktop klientam, kas nāk komplektā ar XP trešo servispaku vairs nestrādā mstsc /console rinda, kas pieslēdzas servera konsoles sesijai.

Neliela meklēšana palīdzēja — tā vietā tagad jāizmanto /admin.