Wypowiedzi
-
Tworzysz cert
#openssl genrsa -des3 -out server.pass.key 2048
Usuwasz haslo
#openssl rsa -in server.pass.key -out server.key
Tworzysz żądanie pospiu
#openssl req -new -key server.key -out server.csr
Wypelniasz pola (ważne aby w "Common Name" wpisac poprawny adres strony)
Podpisujesz cert
#openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Aby zrobić plik "pem" sklejasz:
#cat server.key server.crt > apache.pem -
udało się :)Wojciech Kubiak edytował(a) ten post dnia 27.05.10 o godzinie 14:32
-
.Wojciech Kubiak edytował(a) ten post dnia 27.05.10 o godzinie 14:31
-
A jak jednoczesnie 100 000 userow odwiedzi strone ?
Takie zapisywanie tymczasowe na dysku to nie jest dobre rozwiazanie.
To tak jakbym zamiast uzywac ciasteczek zapisywal sobie potrzebne rzeczy w pliku tekstowym na serwerze :)
Nie ma róznicy dopoki nie uzywa serwisu w danej chwili wiecej niz 1 osoba. -
Działa jak usune filesize i zmienne GET :)
-
Problem w tym ze w headerze powinien byc chyba link do pliku ktory bedzie udostepniony do sciagniecia a nie do phpa ktory dopiero "Zamieni" sie w ten plik. Nigdzie na serwerze nie mam zapisanego wygenerowanego w php obrazka.
On jest tylko w zmiennej i wywolanie pliku xxx.php jako <img ... powoduje ze jest on traktowany jako obrazek.
Po zapisaniu tego co wywala przegladarka zamiast obrazka otrzymuje plik xxx.jpg:
Wojciech Kubiak edytował(a) ten post dnia 26.05.10 o godzinie 15:28
<br />
<b>Warning</b>: filesize() [<a href='function.filesize'>function.filesize</a>]: stat failed for xxx.php?k=SUN&t=sdafasdf&header_sent=1 in <b>/home/watcher/public_html/www/test/zzz.php</b> on line <b>14</b><br />
<br />
<b>Warning</b>: Cannot modify header information - headers already sent by (output started at /home/watcher/public_html/sss/test/zzz.php:14) in <b>/home/watcher/public_html/www/test/zzz.php</b> on line <b>14</b><br />
-
Witam
Problem jest nastepujacy.
Generuje sobie jakis obrazek w pliku xxx.php za pomoca
xxx.php
$img = imagecreatetruecolor($graf_xy, $graf_xy);
(...)
header("Content-Disposition: attachment; filename=xxx.jpg");
imagejpeg($img);
imagedestroy($img);
W innym pliku, powiedzmy yyy.php zalaczam sobie ten obrazek jako obraz:
yyy.php
echo "<img src=\"xxx.php?k=zmienna1&t=zmienna2\">;
Do tej pory wszystko jest ok i na stronie yyy.php wyswietla sie pieknie obrazek. Moge kliknac prawym klawiszem i wybrac zapisz obraz jako. Wowczas zapisze sie jako xxx.jpg.
Chcialbym uniknac tlumaczenia uzytkownikowi ze musi kliknac prawym klawiszem itp... Dolozylem guziczek "DOWNLOAD" ktory kieruje do strony zzz.php ktora ma postac:
zzz.php
$zmienna1=$_POST['zmienna1'];
$zmienna2=$_POST['zmienna2'];
$link = "xxx.php?k=".$zmienna1."&t=".$zmienna2;
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: no-store, must-revalidate, post-check=0, pre-check=0");
header("Content-Type: application/force-download");
header("Content-Type: application/octet-stream");
header("Content-Type: image/jpeg");
header("Content-Disposition: attachment; filename=xxx.jpg");
header("Content-Transfer-Encoding: binary");
header("Content-Length: ".filesize($link));
@readfile($link);
Niestety nie dziala w ten sposob.
Moze jest jakis inny ...Wojciech Kubiak edytował(a) ten post dnia 26.05.10 o godzinie 13:35 -
Router#show debugging
Generic IP:
IP packet debugging is on
IP NAT debugging is on
Router#
IP: tableid=0, s=10.60.17.100 (Ethernet0/1/0), d=81.1.1.30 (FastEthernet0/0), routed via RIB
IP: s=10.60.17.100 (Ethernet0/1/0), d=81.1.1.30 (FastEthernet0/0), g=81.1.1.30, len 128, forward
NAT: s=10.60.17.100->81.1.1.26, d=81.1.1.30 [25]
IP: s=10.60.17.100 (Ethernet0/1/0), d=81.1.1.30 (FastEthernet0/0), len 128, encapsulation failed
Doskonale widać decyzję o forwadowaniu pakietu później NAT zamienia IP z 10.60.17.100 na 81.1.1.26 a następnie pojawia się problem podczas tworzenia pakietu. Moim zdaniem problem jest podczas wysylania zapytania ARP o adres MAC kompa z IP 81.1.1.30. Wtedy okazuje się że taki MAC wystąpić powinien zarówno w polu "source" jak i "destination" nagłówka pakietu. -
To moja przykładowa konfiguracja w PT:
http://kubiak.in/www/NAT.pkt
Myślę że problem jest na poziomie ARPa. RTR1 nie wie jak zencapsulować pakiet do 81.1.1.30Wojciech Kubiak edytował(a) ten post dnia 19.03.10 o godzinie 10:35 -
Maska 255.255.255.248... Przecież dla maski 30 bit miałbym do dyspozycji 2 adresy czyli jeden do użycia (2-gi to gateway) i nie mógłbym skonfigurować statycznego NATu.
W przykładzie dla uproszczenia skonfigurowałem sieć z maską klasy
CWojciech Kubiak edytował(a) ten post dnia 17.03.10 o godzinie 21:35 -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Sieci Komputerowe
-
Dzięki za odpowiedź :) ale jak pisałem wcześniej, NAT działa jak powinien. W tej chwili na routerze RTR1 skonfigurowany jest on tak że "outside" jest tylko na interfejsie do internetu (w kierunku routera GATEWAY) a na pozostałych jest "inside". Jak zmienimy konfigurację NATu na interfejsie w kierunku PC1 z "inside" na "outside" to oczywiście pakiety do 81.x.y.30 zaczną chodzić ale przestanie działać połączenie z internetem ponieważ nie będą NATowane pakiety w kierunku routera GATEWAY.
Żeby spowodować nienatowanie pakietów z PC1 to WWW próbowałem w access-liscie NAT wprowadzić taki wpis:
Wojciech Kubiak edytował(a) ten post dnia 17.03.10 o godzinie 19:20
Extended IP access list NAT
deny ip 10.60.0.0 0.0.15.255 10.0.0.0 0.255.255.255
deny ip 10.60.0.0 0.0.15.255 host 81.x.y.30
permit ip 10.60.0.0 0.0.255.255 any
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Security
-
Witam
Mam problem z dostępem do hosta WWW (10.60.18.3) wystawionego na zewnątrz przez StaticNat jako (81.x.y.30) z Lanu (host PC1 10.60.17.100) który działa pod DynNAT overload.
NAT statyczny i dynamiczny są na RTR1.
ip nat inside source list NAT interface FastEthernet0/0 overload
ip nat inside source static 10.60.18.3 81.x.y.30
I access lista NAT:
ip access-list extended NAT
deny ip 10.60.0.0 0.0.15.255 10.0.0.0 0.255.255.255
permit ip 10.60.0.0 0.0.255.255 any
Rolę "Internetu" pełni w tym przykładzie INERNEThost za routerem GATEWAY.
Wszystko się pinguje, NAT działa poprawnie... ale
Jak spróbuję wysłać ICMP z PC1 do WWW ale na adres zewnętrzny 81.x.y.30 nie otrzymuję odpowiedzi. Pakiet "zapętla" się w RTR1.
Inbound PDU:
SRC IP: 10.60.17.100
DST IP: 81.x.y.30
Outbound PDU (po poprawnym zNATowaniu)
SRC IP: 81.x.y.26
DST IP: 81.x.y.30
Z Packet Tracera otrzymuję komunikat:
Buffer Full: The maximum number of events has been reached...Wojciech Kubiak edytował(a) ten post dnia 17.03.10 o godzinie 12:20 -
Dołożyłem dodatkowy interfejs do WWW1 i na nowej podsieci skonfigurowałem wszystko jak poprzednio. Takie rozwiązanie wydaje mi się najprostsze i przez to najmniej awaryjne. Wszystko działa jak powinno :)
WWW----LAN1-------[router]------LAN2
(80)
|
|
WWW2
(80)Wojciech Kubiak edytował(a) ten post dnia 16.02.10 o godzinie 13:34 -
Wolałbym obyć się bez kolejnej maszyny (kolejne awaryjne ogniwo w łańcuchu) tym bardziej że serwerów WWW nie będzie przybywać.
Idea jest taka żeby ciasteczko sesyjne powstałe na WWW(apache + PHP) było weryfikowalne na WWW2(windows + IIS) -
Ok. Wielkie dzięki wszystkim za pomoc. Rozwiązań mam już kilka. Poukładam sobie jutro wszystko w głowie i na spokojnie spróbuje w praktyce zastosować.
Jak ruszy, dam znać które rozwiązanie wybrałem :)
Redir o tyle nie będzie skuteczny ponieważ idea jest taka żeby ciacho sesyjne zapisywane przez serwisy działające na WWW(linux+ apache i PHP) mogło być weryfikowane na WWW2(windows+ IIS i .NET). Jak mi się zmieni adres w przeglądarce to ciacho nie zostanie odnalezione przez przeglądarkę pod nową "ścieżką".
Pracuję jeszcze nad systemem który będzie działał w oparciu o WebService ale i w tym przypadku jednakowa ścieżka ciasteczka sesyjnego dla obu platform będzie wskazana.Wojciech Kubiak edytował(a) ten post dnia 15.02.10 o godzinie 17:31 -
Tiaaa... tyle że ja mam jeden interfejs sieciowy. Ale przyda się, dzięki.
Coś jeszcze spróbuje pokombinować z wirtualnymi interfejsami. -
Tak właśnie robiłem ale w ten sposób zmienię tylko adres docelowy.
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 12345 -j DNAT --to-destination WWW2:80
Nie powinienem jeszcze zadbać o to aby pakiety docierały do WWW2 z adresem źródłowym WWW1 aby ruch powrotny szedł przez WWW1 ?
W innym przypadku WWW2 odpowie bezpośrednio hostowi który stworzył pakiet dla WWW1. Ten z kolei nie będzie się spodziewał odpowiedzi z innego miejsca niż wysłał zapytanie i pakiet odrzuci.
Próbowałem dołożyć regułkę
iptables -t nat -A POSTROUTING -p tcp --dst WWW2 --dport 80 -j SNAT --to-source WWW1 -
hmmm... subinterface ? A jak na to zareaguje standardowy, niekonfigurowalny switch ?
- 1
- 2