Jeśli serwer ze squidem ma wiele IP, można ustawić, aby przy łączeniu z proxy pod danym adresem IP, również proxy na zewnątrz łączyło się z tego IP:
acl ip1 myip 192.168.0.1
tcp_outgoing_address 192.168.0.1 ip1
acl ip2 myip 192.168.0.2
tcp_outgoing_address 192.168.0.2 ip2
acl ip3 myip 192.168.0.3
tcp_outgoing_address 192.168.0.3 ip3
acl ip4 myip 192.168.0.4
tcp_outgoing_address 192.168.0.4 ip4
acl ip5 myip 192.168.0.5
tcp_outgoing_address 192.168.0.5 ip5
Można do skryptów startowych dodać linię:
echo "1">/proc/sys/net/ipv4/ip_forward
Można też w /etc/sysctl.conf
dodać (lub odremować) linię:
net.ipv4.ip_forward=1
oraz wykonać:
sysctl -p /etc/sysctl.conf
Mamy plik postaci: IP MAC w każdej linii, np:
192.168.10.2 [tab] 00:00:00:00:00:01, chcemy wygenerować wpisy statyczne dla dhcpd.conf.
Używamy skryptu:
for i in `cat ip_mac_dhcp.txt|sed 's/\\t/#/g'`; do
IP=`echo $i|cut -d '#' -f1`
MAC=`echo $i|cut -d '#' -f2`
echo "host $IP {";
echo " hardware ethernet $MAC;"
echo " fixed-address $IP;"
echo "}"
done
Zestawiłem tunel pomiędzy punktami oddalonymi o kilkanaście milisekund, mimo że pomiędzy nimi transfer wynosi kilkadziesiąt Mbps, to w tunelu transfer dochodzi do 4Mbps i nie chce przesyłać więcej.
Okazuje się, że wypełnia się całkowicie bufor podczas wysyłania i zanim kolejna porcja danych zostanie wysłana openvpn oczekuje na potwiedzenie. Aby zwiększyć przepustowość tunelu należy zwiększyć wielkość bufora. Odpowiedzialne za to są następujące parametry:
openvpn –sndbuf 655360 -rcvbuf 655360
(standardowo bufor ma 65536 bajtów, wielkość należy odbrać doświadczalnie, u mnie zwiększenie dziesięciokrotne pomogło).
W debianie argument wywołania można dodać w pliku /etc/default/openvpn dodając na końcu:
OPTARGS=”–sndbuf 655360 –rcvbuf 655360″
Do połączenia z Internetem przez sieć komórkową potrzebny jest demon pppd.
Uruchamiamy go np. tak:
/usr/sbin/pppd /dev/ttyUSB0 921600 connect "chat -V -f /etc/ppp/chat.plusgsm" crtscts modem -detach noccp noauth defaultroute debug ipcp-accept-remote ipcp-accept-local noipdefault lcp-echo-failure 1000
gdzie plik /etc/ppp/chat.plusgsm zawiera komendy AT wysyłane do modemu:
'' ATZ
OK AT+CGDCONT=1,"IP","www.plusgsm.pl"
OK "ATD*99***1#"
CONNECT ''
Jeśli chcemy aby łącze było podnoszone automatycznie po rozłączeniu możemy wywołanie skryptu z wywołaniem pppd umieścić w /etc/inittab, dodając np. na końcu linię:
PP:123456:respawn:/usr/local/bin/gprs.plus.usb
Jeśli karta SIM ma ustawiony PIN należy ustawić go w skrypcie, np. tak:
'' ATZ
TIMEOUT 10
OK AT+CPIN=3141
ERROR AT+CGDCONT=1,"IP","www.plusgsm.pl"
OK "ATD*99***1#"
CONNECT ''
Najprostszą metodą sprawdzania, czy działa łącze, w przypadku braku obsługi protokołu dynamicznego routingu, jest pingowanie hosta i podejmowanie decyzji w zależności od wyników tego testu.
Prosty skrypt może wyglądać tak:
czy=0
ping -c2 156.17.8.1 &&
{
# dziala
echo "pinga";
czy=1
/sbin/ip r |/bin/grep default|/bin/grep -v "10.2.2.1" &&
{
echo "zmieniamy na dialog";
/sbin/ip r d default
/sbin/ip r a default via 10.2.2.1
/bin/date >>/var/log/zmiana.log 2>&1
/bin/echo "wstalo" >>/var/log/zmiana.log 2>&1
}
}
if [ $czy -eq 0 ]
then
# nie dziala
echo "nie pinguje";
/sbin/ip r |/bin/grep default|/bin/grep -v ppp &&
{
echo "zmieniamy na iplusa";
/sbin/ip r d default
/sbin/ip r a default dev ppp0
/bin/date >>/var/log/zmiana.log 2>&1
/bin/echo "awaria" >>/var/log/zmiana.log 2>&1
}
fi
Wcześniej musimy routing do badanego hosta (156.17.8.1) ustawić statycznie przez łącze główne.