Re: ssh-tunnel och brandväggsregler
Hej, externa maskinen heter extern med ip nummer 1.2.3.4 webservern heter server och har två nätverkskort dels 192.168.10.1 och dels 5.6.7.8 den senare (5.6.7.8) är ett fast ip ut mot internet. brandväggen på server tillåter omvärlden att ansluta till port 80 för www anslutningar och till port 21 för ssh men inget annat. webservern har en virtual alias som apache lyssnar till på port 3000. när extern upprättar en tunnel så är det inget problem..men när webläsaren på extern försöker ansluta till localhost:4000 och tunnlas till port 3000 på servern kommer brandväggen att sätta stop för det. Man kan visserligen lösa problemet genom att göra en accept regel för just ip nr 1.2.3.4 men då måste man göra det för varje nytt ip nummer. Jag skulle vilja ha en lösning där det spelar ingen roll vad mitt ipnr utan avgörande för om trafiken tillåts är om jag kan identifiera mig genom ssh tunneln. Hur har du kommit fram till att en sådan extraregel behövs? Trafiken till webbservern borde komma antingen från 5.6.7.8, 127.0.0.1 eller 192.168.10.1 (lite beroende på slumpen och hur du sätter upp din ssh-tunnel, dvs vad du anger för namn/adress med -L). /Pontus -- Pontus Freyhult, see URL:http://soua.net/ for more information.
Re: ssh-tunnel och brandväggsregler
Thomas Nyman [EMAIL PROTECTED] writes: Jag kom fram till genom följande; sitter jag bakom brandväggen går det utmärkt att accessa sidan via ssh tunnel, men sitter jag utanför brandväggen så går det inte. Om jag däremot i mitt iptables script uttryckligen tillåter t.ex 1.2.3.4 att accessa port x dvs dport x ja då går det bra utanför brandväggen. Det låter ju verkligen inte som att du använder tunneln isåfall. Om du kör tcpdump, ser du paket på de portarna ut från 1.2.3.4? In på 5.6.7.8? (det vore förmodligen också bra om du kunde visa din kommandorad, sen är det alltid bra att inte obfuskera om man inte verkligen behöver det). /Pontus -- Pontus Freyhult, see URL:http://soua.net/ for more information.
Re: ssh-tunnel och brandväggsregler
Thomas Nyman [EMAIL PROTECTED] writes: kommandoraden är ssh -i identititet -L 8080:webserver.com:4 [EMAIL PROTECTED] Ser ju okej ut. Jag har ingen tcpdump att skicka just nu, men jag har kontrollerat det hela och tunneln är etablerad. Om jag t.ex befinner mig på en plats som använder masquerading där alla lokala maskiner har ip inom intervallet 192.168.10.11-192.168.10.15 och jag läger till dessa ip i min hosts fil samt i mitt brandväggs skript så fungerar tunneln från externt håll. Av detta kan jag dra slutsatsen att tunneln är etablerad och fungerar som den skall, dvs paket från localhost tunnlas till webservern. Va? Var står webbservern i det här fallet? Hur gör du förresten för att ansluta? Använder du telnet eller en webbläsare eller vad? Kan du visa kommandoraden/URLen? Sen kan du gärna beskriva fungerar inte lite tydligare - hänger den och ger upp efter ett tag eller gör den något annat? Jag tänker mig dock att man kanske kan lösa frågan genom att ange macadress istället för ipadress i brandväggsskriptet, men jag vet inte riktigt hur man anger macadresser..men det kanske du vet? Således skulle man ha en regel som tillåter t.ex all trafik från en viss given macadress... Det går nog inte, det vill säga filtrera på MAC går, men inte i ditt fall (sök på mac i man iptables). (För webbservern kördes väl på samma burk som ändpunkten terminerade i?) fast ännu bättre vore om jag kunde ordna så att när jag etablerar en tunnel anges sourceip som det ipnummer jag skulle ha haft om jag satt bakom brandväggen men vad jag kan förstå är det en teknisk omöjlighet då alla responser hamnar fel..dvs inte når min maskin. ? Anslutningen kommer från någon adress hos den dator som ssh-anslutningen termineras i. Det där med att obfuskera...det är inte så mycket frågan om det som att ha ett intranet som är åtkomligt via internet men endast genom ssh public-key förbindelse. Finns det lika säkra metoder så är jag inte emot att använda dom bara jag vet hur. Obfuskering syftar snarare på de IP-adresser och namn du använder, eftersom jag tvivlar på att du verkligen har adresserna 1.2.3.4 (eller domänen webserver.com). Det bygger ju på att du har förmåga att avgöra vad som är viktig information och inte, vilket ofta är samma förmåga som behövs för att kunna lösa problemet utan hjälp från början. /Pontus -- Pontus Freyhult, see URL:http://soua.net/ for more information.
Re: ipv6
Hej, nånting som finns här i sverig men som jag aldrig fick läsa nånting konkret om är ipv6 backbonet. Vad åsyftas här? 6bone? Något annat? är nån kopplat up mot det? har nån native ipv6 hemma? hur då? Jag har flera v6-anslutningar hem, men alla är v6-över-v4 tunnlar: 1. Dels en privat tunnel genom en förening (där jag inte är medlem, men de förser mig glatt med en tunnel ändå). Det finns ett antal ställen man kan få en tunnel på, men det kräver vissa förberedelser och kan inte göras automatiskt. 2. Dels har jag 6bone-anslutning via SICS (se URL:http://www.ipv6.sics.se/). Notera att 6bone är tänkt att vara utfasat till 06/06/06 i enlighet med RFC3701. 3. Dels har jag även en vanlig 6to4-tunnel till en RFC3068 (6to4 anycast), dvs jag sätter upp en tunnel till 192.88.99.1 och har själv 2002:första 16-bitarna i min v4-adress hexkodade:resterande bitar hexkodade/48. Borde funka ifall ens operatör inte gör några dumheter, hexkodadeoch går att automatisera. Jag rekommenderar i första hand metod 3 och i andra hand metod 1. Metod 2 är lika bra att undvika nuförtiden, tycker jag. /Pontus -- Pontus Freyhult, see URL:http://soua.net/ for more information.
Re: Min /dev katalog har blivit korrupt.
Hej, Eller så är det bug i både MAKEDEV och någon eller några av ovanstående. Om du bara kör MAKEDEV så borde det nog inte hända så väldigt mycket - prova MAKEDEV generic-i386 (jag antar att du sitter med PC-hårdvara) eller möjligen MAKEDEV update. /Pontus -- Pontus Freyhult, see URL:http://soua.net/ for more information.
Re: Studsa med procmail
Hej, Så man måste köra sin egen domän. Det var ju en hake, får väl börja slänga mailen då. Och det var reject jag tänkte på från början. Då riskerar man inte att o-spam kommer bort utan att avsändaren vet. Det hände mig ibland för något år sedan att spamassassin taggade riktiga brev som spam. Jo, det riskerar du iallafall, enligt min uppfattning är det rätt mycket post där eventuella studsar/svar kastas direkt (exempelvis orderbekräftelser, brev med licensnycklar eller bekräftelsebrev/kontoinformation för webbtjänster) som riskerar att märkas som skräp (beroende på hur lika de är vad du matar din spamassassin med). Jag går igenom och tömmer min skräppostlåda några gånger i veckan, det går ändå väldigt mycket snabbare (och är mindre irriterande) än att sortera bort skräpposten från sådan post jag vill ha. /Pontus -- Pontus Freyhult, see URL:http://soua.net/ for more information.
