Source addresses

Use one exact source

Every datagram shredstream.sh sends originates from IPv4 address ${SOURCE_IP}. This includes the one-time verification challenge and the live shred stream. The delivery relay is in ${REGION.city}, ${REGION.country}.

Allow ${SOURCE_IP}/32, not a guessed subnet, region range, domain-name resolution result, or address learned from unrelated traffic. No additional service source addresses are currently specified.

Forgetting this allowlist is the most common activation failure. Apply it before requesting the challenge and keep it after verification because stream traffic uses the same source.

Match the correct tuple fields

An inbound rule should match source IP ${SOURCE_IP}, protocol UDP, and the customer-selected destination port. The destination IP is the public address registered for the paid slot. The source UDP port is not currently specified.

Do not write a rule that requires source port 9000 merely because the destination port is 9000. Source and destination ports are independent fields. Do not use TCP because the service sends UDP.

When a firewall accepts CIDR notation, use ${SOURCE_IP}/32. The /32 prefix selects exactly one IPv4 address. When a tool accepts a host address directly, use ${SOURCE_IP}.

Apply the source at every layer

Cloud and host controls are cumulative. A cloud security group can allow the source while a network ACL or host firewall drops it. Inventory every enforcement point between the public interface and the UDP socket.

1. Identify the public destination interface.
2. Identify the cloud security boundary when present.
3. Identify the network ACL when present.
4. Identify the edge firewall when present.
5. Identify the NAT mapping when present.
6. Identify the host firewall.
7. Identify the application source filter.

Configure the narrow source at each applicable admission layer. An application check for ${SOURCE_IP} is useful for counters and defense in depth, but it occurs after the packet has reached the host.

Validate with packet capture

Replace 9000 with the destination port and run:

sudo tcpdump -n -i any -c 20 'src host 64.130.40.90 and udp dst port 9000'

The filter ignores source UDP port. It exits after 20 matching datagrams. During verification, use -c 1 because the service sends one challenge datagram per request.

Run a second comparison capture only when diagnosing unexpected traffic:

sudo tcpdump -n -i any -c 20 'udp dst port 9000 and not src host 64.130.40.90'

Do not pass traffic from the second capture into the shred receiver as service data. It is unrelated inbound UDP under the documented source contract.

Filter in the application

Check the peer address returned by the receive API before counting or decoding a payload. Compare the normalized IPv4 address with ${SOURCE_IP}. Do not compare a reverse-DNS name because DNS names are not part of the delivery contract.

The following Python condition is sufficient for the documented IPv4 source:

EXPECTED_SOURCE = "64.130.40.90"

data, peer = sock.recvfrom(65535)
if not peer[0] == EXPECTED_SOURCE:
    continue

This check assumes sock is an already bound IPv4 UDP socket. It does not configure the firewall and does not prove that source addressing is cryptographic. Source-IP allowlisting is the product's documented delivery authentication control.

Do not depend on the source port

The source UDP port value, stability, allowed range, and change process are not currently specified. A packet capture may show one value during a test. Do not convert that observation into a firewall condition or production assertion.

A source-port restriction can admit the challenge observed during one capture and later block stream traffic if the sender uses another port. Keep the restriction to source IP and destination UDP port.

Handle address-change assumptions

The product facts specify one source IP and do not define a rotation mechanism, secondary source, DNS record, or advance-notice period. Keep configuration generated from the documented value rather than discovering an address from arbitrary inbound traffic.

Do not auto-add a new source when a packet claims to be service traffic. An address other than ${SOURCE_IP} is not a documented shredstream.sh source. Treat it as unrelated traffic and contact support if an official page appears inconsistent.

Separate source from destination

The service source remains ${SOURCE_IP} when the customer changes a destination. The customer destination IP and port can change, subject to the address-change limit and re-verification. Update the rule's destination port for the new pair while retaining the fixed source.

With NAT, the external firewall matches the public destination port. The internal host firewall may see the translated internal destination address and port, depending on network design. It should still see the sender as ${SOURCE_IP} unless another customer-controlled intermediary rewrites source addresses.

Source NAT performed by a customer proxy can hide the original service source from the final receiver. Preserve the original filtering at the public edge and document the internal proxy address separately. Customer-side proxy behavior is outside the product contract.

Report source anomalies

Record the destination ID, UTC timestamp, destination pair, observed source IP and port, capture interface, and firewall path. Do not claim that a new address belongs to the service based on one packet.

An official address status endpoint, signed source-address list, and source-rotation schedule are not currently specified. Use ${SOURCE_IP} until the single source of truth changes.