Hirdetés

Apache webszerver nem indul az OpenWrt-n

Feltettem egy Apache szervert az OpenWrt-s routeremre, de nem működött. Először azt hittem, hogy kevés hozzá a routerem, de nem így volt. Természetesen az OpenWrt oldala nem említi, hogy az alap konfigfájlal nem fog a telepítés és az ott leírt konfigurálás után kulcsrakészen működni a rendszer....

Az oldal leír pár dolgot. Hogyan kell telepíteni, miket kell beállítani a konfigurációs fájlokban. Természetesen végigmentem én is ezeken. Átállítottam a portot, mivel az alap 80-as port már foglalt, beállítottam a PHP-hez szükséges módosításokat. De az eredmény, hogy webszerver-router IP címét és portját beírva csak forgott a kis frissítés ikon a böngészőben, de semmi nem jött be.

Mit is lehet ilyenkor tenni? Mint minden szerver, az Apache is naplózza a nyűgjeit. Na de, hol találom a naplót?
Az Apache konfig fájlja az /etc/apache.httpd.conf fájl. Ebben meg lehet adni, hogy hova naplózzon a rendszer. Benne is van a konfigban, alapból így elég volt csak rákeresni.

Virtuális Magán Hálózat (VPN) szerver IPSec IKEv2 Strongswan alapokon

Nemrégen írtam egy bejegyzést VPN szerver készítésről OpenWRT vagy LEDE alatt. Akkor az Openvpn megoldását használtam. Most pedig egy IPSec alapú VPN szerver konfigurálási lépéseit szeretném megmutatni Openwrt routeren (de ez akár alkalmazható LEDE rendszerű routereken is) StrongSwan szerver programmal, IKEv2 (Internet Key Exchange Version 2) tunneling protokollal.

Nemrég ismerkedtem meg én is ezzel a VPN megoldással, így a szerver bekonfigurálásának szinte nulla ismerettel álltam neki. Még mindig vannak vakfoltok a dolgot illetően számomra is, így ha rendelkezel nagyobb tapasztalattal, várom kommentben a te konfigurációd leírását is.

A VPN hálózatom felépítése:

Mindenegybenblog új neve

Most vettem észre, hogy a Facebookon lehet javaslatot tenni egyes oldalak nevének és kategóriájának megváltoztatására. Ha megváltoztatjuk egy oldal adatát, az nem változik meg rögtön, hanem egy úgynevezett függő listára kerül. Én próbából betaláltam egy régóta üldözött oldalt a dologgal: a Mindenegybenblogot :)

Íme az én név és kategória ajánlatom. :)


Javasoljátok ti is! Lehet, hogy a Facebook moderátorai elgondolkodnak rajta, hogy ez az igazság :D

A BKK online rendszere

Rádió beszélgetés egy IT szakemberrel és BKK vezérigazgatójával a 18 éves feljelentett "etikus hekker" ügyéről.

Itt hallgatható meg a beszélgetés
33:00 perc hanganyag. [Soundcloud]
(Az első pár perc áttekerhető)

Hogyan lehet több millió publikus ip címem?

Hogyan lehet minden egyes hálózati eszközömnek (PC, Tablet, Teló, IP kamera) egyedi ip címe, amit NAT-olás és DDNS használata nélkül elérek?

Mint tudjuk az IPv4 címek elfogytak, a szolgáltatók manapság, ha nem NAT-olnak, akkor is maximum egy publikus IPv4 IP címet adnak egy felhasználónak (ami rendszerint dinamikus, azaz bizonyos időközönként teljesen más címet osztanak ránk), a helyi hálózati eszközeink rendszerint NAT mögé szorulnak, azok eléréséhez port továbbítási (port forwarding) szabályok írására van szükség.
Az IPv4 címek elfogyása miatt (is) találták ki az ipv6 címzést, ami nem csak hosszúságában tér el az elődjétől. Szerencsére egyre több szolgáltató biztosít ipv6 címet (és mellé egy vagy több címtartományt, szubnetet) a felhasználóknak, de mit tehetünk mi, ha a szolgáltatónk épp nem biztosít ilyet? Erre találták ki az úgynevezett tunnelbrokereket, ami egy publikus ipv4 végpont segítségével ipv4-be csomagolt ipv6 forgalmat biztosít nekünk. Mivel a forgalmazáshoz egy publikus ipv4 végpontra szükségünk van, ezért a szolgáltatónk által nem lehetünk NAT-olva. Ha NAT-olva vagyunk, akkor kérni kell a szolgáltatónkat, amennyiben tud, biztosítson egy publikus ipv4 címet. Sajnos, ha nem tud, akkor nem tudunk tunnelbrokerezni sem, de ha tud, akkor mehetünk regisztrálni a tunnelbroker szolgáltató oldalára.
Mit kell tudni ezekről a tunnelbroker szolgáltatókról? A legtöbb ingyenes, használatukhoz egy ingyenes regisztrációra van szükség. /48 vagy /64-es ip tartományt kapunk egy tunnelhez. /48 esetén ~65ezer szubnetre van lehetőségünk, /64 esetén csak egyre, de abban is lehet több millió eszközünk. Van, amelyiknél több tunnelt is használhatunk, ha van több ipv4 végpontunk. Akár mindegyik végpontra /48-as IP cím tartományt kaphatunk, ami darabonként ~65ezer /64-es szubnet,
Én most a példában a Tunnelbroker.net oldal használatán keresztül fogom bemutatni a tunnelbroker használatot. Hogy emellett döntöttem, abban sok minden szerepet játszott a /48-as címtartomány lehetőségén kívül, de további fontos tény volt, hogy az OpenWRT-s router támogatja a használatát. Azonkívül van az OpenWRT-re való beállításhoz, több leírás, illetve az OpenWRT az ipv4 végpontot is automatikusan tudja frissíteni a felhasználónevünk és jelszavunk használatával.

HowTo: IPV6 bevezetése wifi bridge router mögötti gépeknek

A hálózat:
Már régóta használok másodlagos routert, ami wifi kliensként csatlakozik az elsődleges routerhez. Mindkét routerre vannak kötve vezetékes kliensek, illetve mobilok és tabletek is csatlakozhatnak mindkettőre (a másodlagos routerre egy külön accespointal lehet rácsatlakozni, nem a saját wifijét szórja, az csak a bridge kapcsolatot szolgálja ki). Az elsődleges routerem internet szolgáltatótól ipv6 címet kap a WAN oldalára és ipv6 /48-as prefixet, amit a hálózatom LAN oldalának adhatok ki, így nincs NAT-olás, a kapcsolódó eszközeim közvetlenül elérhetők az internet "másik" oldaláról, egyedi fix ipv6 cím alapján. "/48-as" prefix-et kapok a szolgáltatótól. Ez azért lényeges, mert a bejegyzésben felvetett probléma is csak akkor oldható meg, ha te is rendelkezel subnetelhető prefixel. Természetesen nem fontos /48-al, /56 is elég lehet.

Telekomos IPv6 ip cím tesztelés

Üdv!

Elsősorban Telrkomos előfizetésesek és feltöltőkártyások segítségét kérném.
Tudnátok tesztelni mobilon (mobilnettel, lte vagy akár 3G), hogyha kikapcsoljátok a készüléketeken a mobil adatforgalmat úgy, hogy kikapcsolás előtt van ipv6 ip címetek, majd visszakapcsoljátok az adatforgalmat, akkor visszakapjátok az ipv6 címet, van e ipv6 címetek? Ezt ellenőrizzétek többszöri ki/be kapcsolással. Ezután ugyan ezt kéne tesztelni repülőgép üzemmód ki/be kapcsolással úgy, hogy ezalatt a mobiladatfogalom kapcsoló bekapcsolt állapotban van. A válaszban mellékeljétek a készülék tipusát és oprendszerét, amivel teszteltetek.

Előre is köszi!

VPN szerver ipv6 ip cím kiosztással

Régebbi leírásom alapján összerakott openwrt-s TP-Link routeren futó virtulális magánhálózati (VPN) szerveremet beállítottam, hogy ipv6 ip címmel is kiszolgáljon

Nekiáltam megkeresni, hogy az openvpn konfigurációs állományát mivel is kéne kiegészítenem az ipv6 működésre bírásának érdekében. Rögtön az Openwrt wiki openvpn oldalának ipv6-al foglalkozó részére jutottam. A leírtak szerint beírtam mindent a konfigurációs állományba. Heppy voltam, hogy VPN-en keresztül van ipv6 címem az openvpn kliens telefonomon történt elindítása és a connect gombra történő koppintás után. De hogy miért is legyen egyszerű az élet, az egész nem ment. Hiába volt ipv6 cím, használhatalan volt, pedig a leírást követtem.
Megézem az interfészeket az Openwrt Luci felületén. Látom hogy a VPN és a LAN interfész is ugyan azt a címet kapta meg, amiből már látszott, hogy ez problémás lehet.
Át kéne írni valamelyiket, na de hogyan? Statikusan kéne mondjuk megadni a LAN címet. Ekkor mentem az Openwrt PH! fórumára feltenni ezt a kérdést. Ekkor még nem tudtam, hogy a LAN beállításainál az Ipv6 assignment length disabledre állításával statikusan lehet megadni LAN ipv6 címet és prefixet a hálózatra kapcsolódó klienseknek kiosztásra, ipcím előállításra. Sejtettem hogy az ipv6 asdignment hint is az ipv6 cím módosítára való. Próbálgattam is az opciót, de bármit írtam bele, azt nem vette tudomásul a rendszer. Később szerencsére kiderült a megoldás.
De még mielőtt kiderülhetett volna, megcsináltam a LAN interfészt statikus ipv6 címmel. Hogy hogyan is működött, arról írtam egy hozzászólást az Openwrt PH fórumán. A hsz utolsó bekezdésében vázolt probléma az Ipv6 assignment hint használatával el is múlt.

Tűzfal alap, Ipv6 forgalomhoz - Openwrt

Jegyzet:
Ezeket engedélyezzük input és forward esetében is
echo-reply
echo-request
destination-unreachable
packet-too-big
time-exceeded
bad-header
parameter-problem
neighbour-solicitation
neighbour-advertisement
router-solicitation
router-advertisement

Okos óra

(+vizsga kérdések :DD )