У меня аналогичная конфигурация, в которой некоторые клиенты используют шлюз, который представляет собой -туннелированное устройство VPN, а другие используют обычное интернет-соединение, доставляемое в дом старым интернет-провайдером.
Я не соединяю Wi-Fi и Ethernet на VPN-шлюзе. Вместо этого на этой машине работает VPN-клиент. Это вынуждает VPN-шлюз проверять таблицу маршрутизации для обработки трафика, который может быть обойден мостом.
На VPN-шлюзе у меня три IP-адреса:
basically just a client on my main network
the gateway for the alternate network
this is a VPN tunnel, and the IP is different every time the tunnel comes up
Я также поддерживаю 3 статических маршрута на VPN-шлюзе:
И один важный динамический маршрут для VPN :-10.2.3.5 -> 10.2.3.6
Маршрут по умолчанию к моему шлюзу интернет-провайдера (192.168.1.1 )гарантирует, что шлюз VPN всегда сможет найти Интернет.
Два других маршрута — это два «более конкретных» маршрута, которые охватывают все адресное пространство IPv4. Таким образом, любой трафик в любое место (, кроме любых напрямую подключенных сетей ), передается на интерфейс туннеля VPN, а специальный динамический маршрут туннеля VPN 10.2.3.5 -> 10.2.3.6
передает весь этот трафик через туннель.
Таким образом, все клиенты, получающие доступ к Wi-Fi через VPN-шлюз, перенаправляются через VPN-туннель, и я по-прежнему могу предоставить клиентам доступ к моей сети интернет-провайдера (Wi-Fi ), чтобы получить общий доступ в Интернет, если это необходимо или желательно.
mailx (AKA mail )можно отправлять напрямую, используя опцию smtp
mail -s "test email" -S smtp=HOST2 user@HOST2 < /dev/null
Это говорит ему не использовать MTA с помощью sendmail по умолчанию.
Проблема решена. Вы не можете использовать команду mail
с HOST1 на HOST2, если на HOST1 не установлен MTA. Это работает, если вы используете Thunderbird на HOST1, что соответствует моей цели продемонстрировать, что MTA на HOST2 принимает электронные письма из локальной сети через порт 25