Вот эта. "PAWS" расшифровывается как "Protect Against Wrapped Sequences".
Суть в том, что когда за одним NAT-ом "сидит" много-много-много абонентов, то ему (NAT-шлюзу) в какой-то момент перестаёт хватать TCP SRC портов, и он начинает NATить нескольких клиентов на один и тот же SRC port. Если при этом на сервере включены TCP Timestamps (а они нонче везде включены по умолчанию), то в какой-то момент возникает ситуация, когда на сервер прилетает SYN-пакет "из прошлого", который "благополучно" отметается ядром как некорректный.
Вообще, конечно, в норме такого быть не должно. Потому что чисто математически комбинаций "SRC Port - DST IP" довольно много. И чтобы ситуация воплотилась на практике, нужно чтобы на один и тот же веб-сервер (например) ломанулись бы одновременно 64510 клиентов одного и того же провайдера через один и тот же исходящий NAT-адрес. Верится с трудом. Лично я такого никогда не видел. Но вот народ с ServerFault по ссылке выше утверждает, что ловили такой глюк. А не далее как вчера мне рассказал об этой проблеме один мой знакомый, который тоже встречался с этим в своей практике. Не верить ему причин у меня нет.
Собственно, лично у меня остаётся два вопроса.
- Есть ли какие-то способы лечения этой беды без отключения TCP Timestamps на сервере (что вообще говоря не есть хорошо).
- Как с этим борются в реальной жизни IT-мастодонты типа того же Яндекса или Гугла.
Ну и да. Тем самым лишний раз подтверждается, что при выборе провайдера стоит руководствоваться не только дешевизной и полосой пропускания. С моей точки зрения, если провайдер не даёт прямого ("честного") IP, хотя бы динамического, хотя бы за отдельную плату, хотя бы на "старших" тарифах, то это не провайдер. И по доброй воле втыкаться к нему ни в коем случае не стоит.
P.S. Сбербанк опубликовал вакансию Art Lead. Я не понял, они там что, игрушки делать собрались?