в смысле нат внутрь?
локальная сеть 192.168.100.0/24 натится в 172.25.0.8
потом 172.25.0.0/24 (все подключенные организации) натятся в наш внешний адрес.
я не очень понял что вы имеете в виду. и что за проблема была когда юзеры могли только по очереди пользоваться вашей системой. можете подробнее рассказать?
такой ситуации не будет, когда выполняется nat используется как ключ номер порта, те роутер (в моем случае сервер) “знает” кому что отдать.
есть такая таблица nat, куда записываются данные об исходящем пакете, при приеме же из этой таблицы извлекается локальный адрес, порт и тд
подобная схема получилась только потому, что организации разные.
локалка клиента->nat на серве клиента->впн к нам->nat на нашем серве->инет.
не спрашивайте почему именно так, начальство требует :)
проблема все еще остается, уже не знаю куда копать. они все на нас сваливают, я уже вторую неделю не вылажу из-за доков, скоро все rfc наизусть рассказывать буду :-D
help me please :)
все таки дело не в этом парсере, тк иногда (чаще утром, когда никого нет) файл (любой) может выложиться. днем отключал всех юзеров, оставлял только нат для одного клиента и этого ресурса, и не выкладывается…
на всякие gmail выкладываются сколь угодно большие файлы.
зы поправьте меня если я ошибаюсь,
  • 1) nat полностью прозрачен для клиента, за исключением тех случаев, когда серверная часть приложения находиться за натом.
    2) последовательное применение nat прозрачно для клиента, учитывая п1.
    3) openvpn для конечного пользователя полностью прозрачен ( viewtopic.php?f=16&t=6511#p53765 ). через этот туннель я отправлял большие пакеты, которые доходили до получателя.
    4) всякие nmap, telnet, traceroute по разным портам, с разными размерами пакетов подтверждают п1-п3
    5) на всех серверах с mtu проблем нет, большие пакеты доходят до получателей.
    6) файлы выкладываются используя метод POST, на который могут быть наложены ограничения по размеру, времени выполнения и прочее
    7) учитывая п1-п6 единственное место, где может быть грабля, это их сервер (либо ограничения на post запрос, либо кривое веб-приложение)
    8) вспомнив, что иногда файлы все же выкладываются, я предполагаю, что есть ограничения по времени (юзеров больше, не успевает обработать запрос). причем по таймауту скорее всего вылетает ихнее веб приложение, тк со всех промежуточных серверов проблем с доступом к инету не возникает (в тч и к этому глючному)
уберите секцию archlinuxfr из pacman.conf. эта репа глючит. сегодня у меня тоже проблема с ней.
в домашнем каталоге юзера, проверьте права и владельца у .config/chromium/*
народ я вам сразу сказал что тарить надо систему.
развернуть её просто будет очень.
1) разметить диск
2) смонтировать разделы как они будет в системе
3) тупо распаковать
4) изменить fstab
5) поставить груб
без учета времени распаковки управляемся за пару минут.
зато получаем возможность спокойно сменить винт на более емкий, возможность изменить количество разделов, их порядок, фс и тд
можно этот же архив слить в образ и пошаманив с загрузчиком и парой скриптов записать систему на болванку
тк систему тарим, архив сожмется, раза в полтора точно + в архиве можно быстро заменить отдельный файл ;)
дык вы адрес не получаете/ставите.
+ еще когда юзаете wep нужно тип ключа указать:
iwconfig ... key open
и только сейчас
iwconfig ... key s:12345
потом
dhcpcd wlan0

iwconfig
wlan0 Ralink STA ESSID:“Con” Nickname:“RT2870STA”
Mode:Ad-Hoc Frequency=2.412 GHz Cell: 72:98:50:0F:12:69
Bit Rate=1 Mb/s
RTS thr:off Fragment thr:off
Encryption key:off
Link Quality=70/100 Signal level:0 dBm Noise level:-115 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

iwlist wlan0 scan
wlan0 Scan completed :
Cell 01 - *тут была сеть соседа, решил, что она не важна*
Cell 02 - Address: 02:1E:65:01:00:0B
Protocol:802.11b/g
ESSID:“Conn”
Mode:Ad-Hoc
Channel:11
Quality:100/100 Signal level:-37 dBm Noise level:-115 dBm
Encryption key:on
Bit Rates:11 Mb/s
ну по идее кому как удобнее, тот так и сделает :)
я же не вижу смысла на таком низком уровне делать архивы, мне проще затарить сразу всю систему, а потом просто распаковать :)
так кстати дженту ставиться, монтируются образы и распаковывается затареный стайдж3 ;)
зы просто вопрос вдогонку, dd на lvm корректно запишет образ?
dd и нулевые байты скопирует ;) без дополнительных телодвижений такой архив весит больше :)
и архивов несколько будет :) по одному на раздел
а если тарить то архив один получиться :) да , перед распаковкой придется смонтировать все разделы, зато распаковка в одно действие получиться :)
ну в таком случае проще затарить всю систему с лайвсиди какого-нибудь. потом с того же лайвсиди разметить диск, смонтировать все что надо и распаковать, не забыв fstab поправить
в случае с dd неудобно распаковывать будет, если винт другого объема